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In this Issue 

The Digital Data Storage or DOS format for tape drives was developed in 1989 to 
meet the need for high capacity, compact tape backup for network servers and 
small multiuser systems. The DDS standard is based on the Digital Audio Tape or 
DAT standard and has been extended as backup capacity requirements have 
increased. DDS-2 drives have recently become available, and higher-capacity 
DDS-3 and DDS-4 specifications have already been approved. DDS-2 drives can 
store four gigabytes of data on a single cartridge, or typically eight gigabytes 
with 2-to-1 data compression. The HP C1533A DDS-2 tape drive can record a full 
DDS-2 cartridge in just over two hours, running at a data transfer rate of 510 
kilobytes per second. This is almost an hour faster than typical DDS-2 drives. As 
explained in the article on page 6, achieving this performance required improvements in tape material, tape 
length, tape thickness, read and write heads, drum design, and linearity measurement and adjustment. 

For many systems, eight gigabytes isn't enough, and it isn't convenient for the typical user to change 
cartridges during the backup, which must often be done at night. The HP C1553A DDS tape autoloader 

was developed to meet this need, As Steve Dimond tells us in the article on page 12, the size constraints 
gave the designers their major challenge. The autoloader had to fit into a standard 5 '/4-inch peripheral 
enclosure (about 5,75 inches wide), incorporate the four-inch-wide HP C1533Atape drive, hold as many 
tapes as possible, and be reliable and ergonomic. "As many tapes as possible" turns out to be six, giving 
the autoloader a typical capacity of 48 gigabytes with 2-to-l data compression. Different strategies for 
using this capacity for network backup are discussed in the article. The complex retry algorithms required 
for controlling the autoloader are defined in state tables, which are generated by an automatic tool that 
greatly increases readability and maintainability, as explained in the article on page 21. In a companion 
article, on page 27 r firmware designer Mark Simms shares with us his experience using different ap- 
proaches to tho implementation of state machines, exploring the advantages and disadvantages of each 
approach. 

Debuggers are software tools that are used by software developers for finding bugs in programs and for 
analyzing programs. The debugger described in the article on page 33 is called HP DDE, which stands for 
distributed debugging environment, meaning that this debugger can debug programs running on remote 
computers. It's an event-based debugger, which means that it responds to user-specified events that occur 
during program execution. It consists of a main debugger that communicates with several modules called 
managers, which handle dependencies on specific languages, object code formats, target platforms, and 
user interfaces. This modularity has made it easy to retarget the debugger to many different languages 
and computer platforms, both HP and non-HR 

Most engineers are familiar with Fourier analysis, in which a time-varying voltage is expressed as the 
sum of a set of sinusoidal basis functions of different frequencies and amplitudes. Wavelet analysis, 
described in the article on page 44, is similar, but the basis functions, called wavelets, are not sinusoidal 
and are localized in time and frequency. The properties of wavelets make them useful for processing 
nonstattonary signals such as a sum of gliding tones or a sum of three signals that start at different 
times. The article gives an overview of wavelet analysis and describes a software toolbox created by 
HP Laboratories Japan to aid in the development of wavelet applications. 

Test vector is a test- engineer term for a pattern of ones and zeros that an automatic tester applies to the 
inputs of an integrated circuit or a printed circuit assembly to make sure that it works. Generating and 
verifying test vectors is a nontrivial process that's carried out with the aid of specialized software tools 
and can take six months or so to complete. As explained in the article on page 55, engineers at one HP 
laboratory have been able to reduce this time to four months, thanks to five techniques that mainly verify 
that the test access port is functioning properly. 
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It's known that detecting and fixing software bugs eariy in the development cycle is much less costly 
than dealing with them fate in the cycle. Software inspections are one means for early bug detection. 
One HP software laboratory has used data collected during inspections and testing to estimate the value 
(expressed as the return on investment! of inspections and early testing. Their results show a return on 
investment of 787% for inspections, compared to 229% for testing. Details are in the article on page 60. 

The latest generation of high-performance microprocessor chips operates at clock rates up to 150 
megahertz and leaves little room for imprecision or uncertainty in the clock delivery system. Using Intel's 
Pentium™ chip as an example of this new class of processors, tfie article on page 68 shows that the 
jitter tolerance for the clock delivery system can be as low as 5D picoseconds, making it essential to use 
a low-jitter signal source such as the HP8133A pulse generator when making measurements on such 
systems. The HP 81 33A's jitter specification of five picoseconds (rmsl ensures that most of the measured 
jitter comes from the clock delivery system and not from the signal source. 

The report on page 80 presents some recent results of an HP Laboratories project aimed at modeling 
and simulating a manufacturing enterprise. The goal of this ongoing research is to learn to predict the 
likely results of changes using sound engineering principles and techniques. The results in this report 
are from simulation experiments using a mode! called the Simple Model hecause of its structural sim- 
plicity. Despite its simplicity, the model displayed complex dynamic behavior and produced unexpected 
results. The author suggests that application areas for enterprise modeling and simulation include esti- 
mating the effects of incremental improvements, studying the impacts of process changes, generating 
enterprise behavior information, and increasing the chances for success of reengineering efforts. 

R.P. Doian 
Editor 



Cover 

An exploded view of the interior of the HP C1553A DDS tape autoloader, showing the C1533A DDS-2 tape 
drive (shiny rectangle) and the small amount of space around it that was available to the autoloader 
designers. Also shown is the six-cartridge autoloader magazine in the front-panel door. 



What's Ahead 

Lightwave topics will dominate the February issue with twelve articles on new products, devices, and 
techniques. We'll also have an article on a new sequencer architecture that greatly reduces the time 
required to write tests for serial digital devices, and several articles on aspects of JG design from the 
1994 HP Design Technology Conference. 



Pan Hum is a U S r-ademarlt ul Intel Corporjitinn. 
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Fast DDS-2 Digital Audio Tape Drive 

Running at a data transfer rate of 510 kbytes/s, the HP C1 533A tape drive 
can record a full 4-Gbyte DDS-2 cartridge in just over two hours, almost 
an hour less than typical DDS-2 drives. Its development required 
improvements in tape material, length, and thickness, new read and write 
heads, a new drum design, and new methods for linearity measurement 
and adjustment 

by Damon R. Ujvarosy 



Like all aspects of computing today, the face of mass storage 
is changing rapidly- ( h\ly a few short years ago, gigabytes of 
disk storage was the domain of large computer systems, 
tfi nised in computer rooms with dedicated staff to look after 
the eqtnjmieni. Personal cnnipiUcrs thai had nunv ihan 100 
megabytes erf disk storage were a rarity, and networks were 
just coming of age. The individual computer user rarely con- 
sidered backup. Critical data was kept on large computer 
systems and backup to tape was handled by the MIS depart- 
ment The odd file on the PC" that was important could be 
saved on a diskette. 

Times have changed rapidly, fndi vidua! PCs with several 
hundred megabytes of disk storage are common. Network 
servers for PCs and workstations have multiple gigabytes of 
disk storage. The data on these disks is critical to ihe com- 
pany's business. High-performance, high-capacity backup 
solutions that fit the needs of today's computer systems are 
essential. 

The same technologies I hat are propelling disk drive capac- 
ity and performance arc also being applied b> tape drives. 
Tape drives that meet the backup needs of the individual PC 
user are available using the D( .'2000 minicartridge — for ex- 
ample, the IIP Colorado Memory Systems Jumbo 260 and 
Jumbo 700 tape drives. However, the backup needs of the 
network server are far greater. These large] backups also 



require improved performance to complete the data backup 
in a reasonable time. 

The Digital Data Storage (DDS) format standard was devel- 
oped by HP and Sony in the late 1980s io establish a capacity 
and performance point that would serve Ihe emerging net- 
work server market as well as the more established small 
multiuser systems market. The DDS format standard is 
based on ihe Digital Audio Tape (DAT) standard, which uses 
4-mnvwide tape Tape drives that employ the DDS format 
standard are therefore often referred to as DAT or 1-nim 
tape drives. 

In HP DAT drives, lossless data compression was added 
later to the DDS format standard using an HP-developed 
method called DCLZ, 1 an implementation of a technique 
known as Le m p el-Zi v d ai a co m p i e ss i < m . - DCLZ e f f ec t i vc ly 
doubled the capacity and performance ol the tape drive, and 
at the same time, longer tapes were added. Four gigabytes 
could then be stored on a single DDS tape. Further extern 
SlOttS to the DDS formal standard that will allow the DDS 
format to serve Ihe backup needs of network servers 
through the end of the 1990s have been agreed to by the 
DDS manufacturers group (see Fig. 1). 

The HP ClottiA DDS-2 tape drive (Fig, 2). introduced in 
1993, stores eight gigabytes of data (typical capacity 
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DDS-1 



Fig, 2. T\ ie HJ I ! »-J tape drive has a native-mode da 

transfei ■!■■■ fe* 

cords on high -capacity I Gl . onearliei I 

■ha. 

achieved using the DCLZ data compression standard) and 
has a data transfer rate more than 2.5 times that previously 
available on DDS tape drives. The HP CI 533 A not only reads 
and writes tapes based on the DDS-2 format standard, but is 
also able to read and write tapes based on the original DDS 
format standard to provide compatibflits wiih the large 

installed 1>;lsc of 1)1 »S tape drives already in existence 

III. I HJS-2 formal standard rails for the data to he wilt ten 
on tracks that are nominally 9.1 \kn\ wide as opposed to the 
previous DDS format standard, which used a I3,6*um hack 

width, The DDS 2 formal standard also makes use of tapes 
that are 12(> m long rather I ban the previous 90-m and 60*111 
tapes. These changes, defined by the DDS-2 format stan- 
dard, along with a data transfer rate increase to SICi kbytes/s 
from 183 kbytes s | the data transfer pate seen by the user is 
effectively doubled io over 1 Mbyte/s by the use of data 
ijiiissiuiu required numerous technical developments. 

Media 

The media used for DDS-2 are an enhancement of the exist- 
ing DDS t iiMu and 90-rn media Ph$&ully. u 
look similar; they use the same < art ridge shell and are all 
designed to meet the same environmental and data reliabil- 
ity specifications. What differentiates them, aparl from the 
packaging, as fiie length of tape In the earteidge shell and the 

signal eharaeteri sties or recording properties of the media. 
The tape drive different tales between the earl ridge types by 
the useol m ■ogniiiiHi holes m the cartridge shell 

Tlie longer lape length is achieved h\ reducing thr total 
thickness of the tape so ihai the lape pack vol i is the 

same fur 1 2D in as for 60 m and 90 m. Fig 3 shows Ihe nla 
i i v i ■ thicknesses of the three DDS media types and a BimpH 
fied view of the construction of the tape, To provide optimal 
head -tod ape contact when switching between the different 
tape thicknesses (the drive needs to read and write DDS-1 
tapes as weD as DDS-2 tapes) iJ^stilfoess of the tapes needs 
i" in matched aa closely as possible, However, because the 
relationship beWeferi tape thickness and stiffness Is a cubed 
jaw, use of the same base film materia] is not possible \ 

new base film material, pulyainidi' or PA. has hren developed. 
It has higii stiffness, ami by carefid design of the heads and 
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fcerathalste 1'KN = polyethylene rtaphtalate. PA = pojyami 

drum, the ability to switch from one tape type to another 
can be optimized. 

The 120-m tape, at6<5-um total thickness, offers the thinned 
media currently in use in the data recording industry, This 
has necessitated improvements in die accuracy of the tape 
guidance system within the tape mechanism and in ihe tape 
motion tension control servo Of the mechanism to prevent 
media damage, 

The use of thinner tracks reduces the overall system signal- 
lo-noise ratio and the tape was called Upon to make a con- 
tribution to reducing the deficit. An to reaseof +'3 dB o#er 
the existing DDS media was needed Kxtsiing (i0-m and 00-m 

media use metal particle (MP) codlings. To meet the addi- 
tional signal requirements at) enhanced Mr tape has heeu 
developed and has been designated MP+, By usiun a combi- 
nation of magnetic particle size reduction, increased coer- 
civity, increased remanecce, and reduced surface roughness 
nf the media. the additional signal requirements w* 
achieved. 

The higher head-fo4ape s&eed nf the IIP C1S33A DDS^2 tape 
drive compared n> previous DDS drives places additional 
constraints on the media. Without efficient luhrication the 
surface of the media is damaged reducing ihe life gJ 
media Then is alio the possibilitj Of Ihe heads becoming 
■ togged with debris from the media. To reduce this effect 
the lubrication has been modified for DDS-:: 

Heads 

Thr changes needed Ioj I >i >s 2 also called for modifications 
to the head& A DDS tape drive has four heads mounted on a 
rotating drum. Two heads are used for writing and two for 
reading. The tape is wrapped mound the drum over an angle 
dial is uominallA 90 degrees (see Fig, 1) so that only one 
In ad is in contact With the tape at any given time. 

During a write, the first write head [designated the A write 

head) contacts the tape and data is written with :in azimmh 

ringii of 2h(ic^rees The first read head (designated the A 
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Direction of Rotation 



B Write Head 



A Read Head 




Fig. 4. The [)KS i ,,[..■ hive has four heads mount <■'; hi a h i,.mi,u 
druriL Only erne head at atfaije is in contact wirh bhe toed&t, 

read head) con tacts the tape next In verify flic previously 
written data. The second write head (designated the B write 
head) contacts the tape next to write data v\ ith an azimuth 
angle of -20 degrees. The second read head ( designated the 
B read head J contacts the tape next to verify the data pre- 
viously written by the B write head. During this process (lie 
tape is moved forward to produce data on the tape as shown 
in Fig. 5. 

To accommodate the higher coercivity of J he DDS-2 tape 
media the write head was changed from n Sendusit-based 
head to a metaJ-in-gap (MIG) style ferrit.e-based head (see 
Fig, 6). The MIG head ensures thai the magnetic coating on 
the tape is fully saturated during the write process. Sendust 
is still used in (he head, but only for the gap metal and not as 
die bulk material. 

The read head required several changes to meet the needs ol 
the HP C1533A. The first was to change from a Sendust- 
hased head to a ferrite-based head. This was necessary to 
maintain the nominal head life specificatiuii of §000 hours. 
Since the HP 01533A has a data transfer rate that is 2>87 
times the previous generation of DDS tape chives, die head 
is in contact with the tape media 2.87 times more dming that 
6000 hours. The ferrite-based bead is harder than the Sen- 
dust-based head and meets the life requirements. 

The second change to the read head was to the width. The 
nominal width of the read head for the DDS format standard 
was 20.4 um, A read head of this width on a 9,1-um wide 
DDS-2 track would allow 7 too much adjacent track noise to 

t Sendust is an altov of 85% Fs, 6% Al, and 9% Si, Jt was developed at the University of Sendai, 
Japan 

Data Written by the A Head 



Data Written by the B Head 




fi°22 39 



Fig. 5. f 4 IS-2 I ni'i !'■ >r:iiat on tape. 




Fig. 6. The lit- 1 < 11533 v ^ tape drive hgs t&etal?frk£ap h- nil* -based 
write heads. 

be picked up, thereby reducing ibe signal-to-noise ratio below 
an acceptable level. At first glance il would seem that a read 
bead width of 9,1 um (equal to The nominal written track 
width) would be optimum (maximum on-traek signal pickup 
with minimal adjacent-track noise pickup). Tins would be 
valid it the tracks were ail perfectly straight However, the 
DDS-2 standard calls Tor the tracks to be straight within ±2.5 
um over the length of the track (called linearity) to allow for 
mechanical tolerances in the tape chive. While a 9.1 -urn- wide 
read head would provide an excellent signal-to-noise ratio 
on a perfectly straight DDS-2 written hack, it would not be 
able to read a worst -case DDS-2 written track that was writ- 
ten by a different drive (see Fig. 7). In this case, the read 
head would have a large adjacent-track noise pickup with a 
relatively small on-track signal pickup. Since the ability to 
interchange tapes between tape drives was an important 
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consideration in the design of the HP C1533A tape driv* 
balance needed bo he struck to achieve the optimum read 
head width. A 12-uju read head width was specified through 

fie of computer modeling of the effect of aojacen [-track 
noise on signal-to-noise ratio. Experiments verified the 
performance of the 12-um head. 

Drum Design 

The next major challenge came in the drum design. The 
increase in the data transfer rate to 310 kbytes/s from I 
kbytesfe required an increase in the drum rotation speed, to 
$737 r/min from 2QQQ r ntitf, The majoj contend 

with were drum bearing life, acoustic ro use at the higher 
rotation speed, and excessive air between the drum and the 
tape. Excessive air would force the tape too far away from 
the drum, resulting in reduced signal levels because of loss 
of contact between the head and the tape, 

A great deal of work has already gone into bearing Me and 
acoustic noise in high-rotation-rate spindle motors for disk 
drives. The key to bearing life is the proper choice of lubri- 
cants. By using the same high-performance lubricants that 
are found in disk drive spindle motors* we were quickly able 
to meet the bearing life requirements of I he HP C1533A tape 
drive. 

The acoustic noise generated by the drum is largely a func- 
tion of The control system. The control algorithm used in the 
HP C1633A tape drive reduces the high-frequency content of 
the control signals so that the acoustic noise of the HP 
C1533Ais comparable to previous-gene ration DDS tap* 
drives 

The problem of excess air between the drum and the tape 
required the development of techniques to bleed away the 
excess air to ensure thai proper head-to-tape contad was 
maintained. Several techniques were prototyped and carefully 
measured by HP Laboratories for their impact on tape defor- 
mation. Among the Techniques prototyped was a 'window- 
less" drum, in which there is a gap between the lower, sta- 
tionary scetion of the drum and the upper, rotating section of 
I he drum. The gap provides a path for ihe air to bleed away 
and eliminates the need for a "window" around the head. A 

second technique prototyped was a standard wicdo 
drum with a small chamfer along the bottom edge of the 
upper rotating sect i on of the drum to provide the necessary 
air bleed (see K114. B) 

In the end, the window style drum using ;i ehnmler on the 
lower edge of the rotating section of! he drum was Immd to 
be 1 he best solution, ensuring thai the tape was not damaged 
w T hile providing an easily inanufarturahie solution to the 
problem of excess air between the drum and the tape. 

Linearity 

As previously mentioned, the DDS-2 specification calls for a 
maximum deviation from a straight line of ±2. ft um fdl -> 
written track This specification is referred to as linearity. 
The linearity of the pre* n »ua generation of DDS tape drives 

measured and found to have a mean value of 3,7 um and 
a standard deviation ol 0.71 um. To meet the DDS-2 specifi- 
cations, an intensive research activity was undertaken at HP 
Laboratories, That research determined ihai ihe linearitj 
measurement and adjust mem process would have to be 
changed bo meet the DDS-2 specifications consistent^. 



Previously, linearity was measured by writing a tape, physi- 
cally cutting out a section of that tape, developing the tape 
using ferro&mds tu be able to see the written tracfe, and 
then measuring the tracks under a microscope. This tech- 
nique suffers from two problems. First, the measurement 
error associated with the technique w as found to he up to 
2 urn. Second, the technique did not allow the linearity to be 
measured m real nine while adjustments to the guides were 
being made on the 

The problem of measurement error was tackled by develop- 
ing an automated optical measurement system Using optical 
patient recognition software, the system automatically finds 
special written patterns on the tape. A precision coordinate 
measurement system measures the track position relative to 
die edge of the tape. The system is calibrated with a chrome 
optical standard and a measurement accuracy of +0.15 um is 
achieved. 

This optical measurement system is used to measure the 
aba iliim linearity of tapes. These tapes are then used as a 
reference for a real-time measurement system in produc- 
tion. Special patterns written on the tape are used by die 
tape drive under test to measure its own deviation along the 
track relative to the tape in the drive. By subtracting out the 
measured linearity deviation of the tape in software, an ac- 
curate real-time measurement of the linearity p# die drive 
under test is achieved. It is then possible for a product ion 
operator ro adjust ihe tape guides for minimum linearity 

sation as port of the standard production process. The 
use of these linearity measurement and adjustment methods 
I iris allowed HP 10 reduce the mean linearity deviation in 
production (o 1.4 ton with a standard deviation of 0.33 um, 
well within the DDS -2 specifications. 

Performance 

The network server market that the IIP C1533A tape drive is 
designed to serve requites high performance as well as high 
rapaeity. The data transfer rate of r>lt) khyies s is an imper- 
ial u factor in the performanei » of the HP CI S33A tape drive 
since it defines the maximum rale at which data (after com- 
pression) can be written lo or read from the (ape. The actual 
performance the user wil3 see in a system is a function of a* 
least thirteen factors, Some of these Bactorsarea Function of 
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the tape drive, but many are dictated by the system using 
the tape drive. The major performance factors, along with 
the corresponding controlling functions, are listed below. 



Performance Factor 

Data transfer rate 



M i i x i mum data com p r ess i on 
ratio that maintains 
maximum tape drive 
transfer rate 

Data compression ratio 

Main buffer size 

SCSI transfer rat e 



Data transfer size 



Controlling Function 

Tape drive if desired data 
transfer rate is greater 
l han maximum tape drive 
transfer rate 

Computer system if desired 
data transfer rate is less 
than maximum tape drive 
t i ansfcr rate 

Tape drive 



Data 

Tapedriw 

Limited to the maximum SCSI 
transfer rate that both Ihe 
tape drive and the computer 
system can achieve 

Computer system 



The architecture of the HP C15B3A eontroUer is outline] In 
Fig. 9. 

An examination of the write process is instinctive in under- 
standing the potential performance limilers. The following 
are the major steps in the write process, 

1. Computer system negotiates SCSI transfer rate with the 
tape drive. 

2. Computer system establishes transfer size. 

3. Computer system transfers data to the tape drive, 

4. Tape drive compresses the data through the data com- 
pression processor and moves the data into the main buffer. 
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Fig. 9. Olo^k diagram of the HP ClfrttA ra] .<■ rjiftne < out roller. 




'. Format processor divides r lie data into DDS formal stan- 
dard groups and adds access and indexing data to enable 
high-speed search and retrieval and error correction fields 
io maintain data integrity on reads. 

6, DDS format data is written onto the tape. 

To achieve maximum performance, it is essential that DDS 
format data is available to write onto the tape at all limes. If 
no data is available, ihe tape drive will have to slop writing 
data and wail until data is available before restarting the 
write process. The tape will also have to be repositioned 
before the next write can begin. The format processor must 
of course have the abilin to take the dala from the main 
buffer, convert the data into the DDS format and compute 
the eiror correct ion values in real time or Ihe tape drive will 
never achieve its full performance 

The main buffer performs a speed matching function, giving 
the flat a compression processor the necessary freedom to 
output data ai a varying rate while keeping the tape drive 
streaming. Modeling demonstrated that a buffer size of 1M 
bytes is sufficient, to maintain the performance of the HP 
C1533A tape drive in most applications. 

The maximum speed at which the data compression proces- 
sor can take uncompressed input data and output it as com- 
pressed data is another factor in Ihe performance picture. 
II ie more compressible the data, the faster the data compres- 
sion processor needs Io be to maintain an output rate dial is 
fast enough to keep the tape drive streaming. An average 
compression ratio of 2 to 1 is the accepted industry norm for 
typical computer data. However, within a large backup, the 
compression ratio of individual tiles will vary tremendously. 
By studying a large number of backups, we were able to BS* 
tablish that the data compression processor needs to be capa- 
ble of about 4-o>I compression at full output rate to main lain 
an overall 2-to-l compression rate. We therefore designed 
the data compression processor for the HP CI583A to meet 
this requirement. 

The last major piece in Ihe performance picture has to do 
with the ability of the computer system to move data to the 
tape drive. To get die maximum performance from the tape 
drive, it is important that the com [niter system provide the 
i lata as fast as the (ape drive needs it The maximum rate at 
which the data can then be transferred to the tape drive is 
determined by the negotiated SCSI transfer rate and the 
transfer size that the computer system establishes. The SCSI 
transfer rate is the lower of the computer system and tape 
drive max i inn in rates. If the computer system's maximum 
SCSI transfer rate is less than The tape drives maximum 
SCSI transfer rate, the SCSI transfer rate used will be that of 
the computer system, The slower the transfer rate, the less 
time there is to cover any system overhead. Additionally, if 
the computer system establishes a small transfer size, the 
data transfer will occur in small increments- Since each 
transfer has overhead associated with it T small transfer sizes 
will have relatively more overhead which will likely reduce 
the performance of the tape backup (see Fig. 10 ). 
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DDS-2 Tape Autoloader: High-Capacity 
Data Storage in a 5!/4-Inch Form Factor 

The autoloader holds six 4-gigabyte cartridges. With data compression, it 
can back up typically 48 Gbytes of data overnight or 8 Gbytes every day 
for six days, unattended. 

by Steven A. Dimond 



The i tend from centralized computing data centers to PCs 
and client-server networks has led to increased local or 
semilocaJ data storage and backup. As discussed in the pre- 
ceding article, DDS tape drives are designed Lo meet these 
requirements. However, as netw T ork sewer disk capacities 
increase above the capacity of a single DDS tape (8 giga- 
bytes for DDS-2, compressed), or if manipulation of the 
backup tapes becomes a chore, then there is a requirement 
for a larger storage device. 

The type of person who carries out the backup has also 
changed with these trends in computing. The centralized 
data center had trained, lull-lime operators, whereas the 
network administrator or workstation user may not be for- 
mally trained and will want to spend the minimum time and 
effort completing the backup. 

These requirements for storage capacity and ease of use have 
led lo a need for an automated, easy-to-use, large-capacity 
tape device. 

One way to add significant capacity al modest cost is to use 
a changer mechanism (robot) to select a tape from a library 
of tapes and put it into the tape drive. The changer mecha- 
nism may only double or quadruple the cost of the tape 
drive unit, but the capacity can increase many times more 
than tliis. There are tape libraries that have from 10 to 120 
Tapes and one or two built-in tape drives. The access times 
to select a tape axe acceptable for a backup or library type 
application. 

Given the emerging network requirements, there is an even 
bigger need for a small device that tits the standard Ti'j-mch" 
peripheral slots. These are approximately 140 nun wide by 
83 mm high by 203 mm deep (5.75 in by '125 in by 8 in). This 
is enough volume to hold a smaller peripheral -size tape 
drive and a changer mechanism. 

These smaller devices that perform unattended backup are 
typically called autoloaders. At HP's Computer Peripherals 
Bristol division, we investigated this growing need. This 
investigation led to the development ot the HP C1553A 
DDS-2 digital audio tape autoloader. Fig. L 

The HP CI 553 A autoloader incorporates the IIP C1533A 
DDS-2 tape drive described in the article on page 6. It holds 
six DDS-2 cartridges, each having a nat ive capacity of four 
gigabytes. With data compression, eadl Cartridge ran hold 
typically eight gigabytes, giving the auToloaifeiC tfae ability to 




Fig. l.Thv HP C1553A DDS-2 digital anr In i in|"- mimloader contains 
a DDS 2 r.-i[.i- drh e and % Cartridge changing mechanism that :-;■ h •■ i :-> 
urn< i»t' yi>: cartridges from a rnsgazane and loads \\ into the drive. 
' "i Edges -ic changed automatically i j 1 1 • 1 • i s- ifc w;u- ■ mm ml. 

back up typically 48 gigabytes without operator interven- 
tion. Two standalone versions are available: The IIP 6400 
Model 4SAL for HP 9000 workstations and the HP SiireStore- 
Tape 1200e for Novell Netware and Windows NT systems. 

Design Objectives 

The basic definition for the HP CI 553 A autoloader was very 
simple. It was to be a DDS tape autoloader, fit into a stan- 
dard 5 L , 4-inch peripheral enclosure, use a standard HP DDS 
drive with minimum (or no) modifications, use the drive's 
SCSI II interface, hold as many tapes as possible, and be 
reliable and crgonumic. 

During the investigation phase for this product there were 
prototypes of similai products available. To keep I he invest- 
tuenl low we considered procuring one of these designs. 
However I hey fell short of some of Ihe requirements, so the 
decision was made to produce our own design. 

Given I he small size of the product and the desire to accom- 
modate as many tapes as possible, the interior space was at 
a premium. Despite frequenl questioning by the engineers, 
the outside dimensions could not be increased if we were to 
be sure of satisfying the maximum number of customers. 
One possibility was to have a "power bulge 1 * on the rear of 
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ait. but this was 'i because it might obstruct 

si une custon u : iai ions. 

It was decided that the new HP C1533A DDS-2 tape drive 
was to be fitted inside the autoloader For reasons of manu- 
facturing simplicity and cost, the drive had GO \w used wiih 
minimum modification. We were also aware that the auto- 
loader would be a platform for future DDS drives, 
integral ion was important for future generations as well. 
The price of the autoloader could perhaps be only double 
that of the DDS-2 drive for several times the capacity 

si ii interface of the built-in drive can I ■ 
pass on control commands to the changer mechanism. Thus 
the customer need only use one SCSI bus ID where some 
libraries require two. 

The more tapes the device can hold, (he more attractive a 
product it will be Competing autoloaders with four car- 
tridges were known to be under development, so our goal 
was to mar rJ i rlns number or exceed it. 

We saw the magazine holding the tapes as a simple storage 
solution, thai is, inexpensive and Capable of being stored 
like a video tape, This allows ihe user to treat a magazine as 
a big siii«li [j I ape, rather than having to manipubi 

lot of single tapes. 

For reliability and ease of use* use models and metrics w 
developed, hi the eaifo stages of development, user tests 
were conducted on possible design concepts. 

Pin sical Architecture 

The physical archil eel urc is dominated bv the lack ofspa 
[ n ring the :!' >it\eh C1.-W1A tape drive into the volume al- 
lowed for I he autoloader accounts for mueh of the difficulty. 
The drive is placed at the rear of the autoloader vol nine be- 
cause it has its interface connections at the rear and die 
tape loading at the feont. There is just enough space lor a 
tape in front ol " ihe drive, bur unfortuuiiiely no ErontrtO-reat 
room for a mechanism- However removing the linm panel 
(bezel) of the drive, which is not required, creeled a vital 
few extra millimeters. 

The construction of the limit of the DDS-2 drive is such thai 
the tape can overlap the drive when ii is ejected, thai is, the 
rape can extend inlo the drive about 1 1 mm. This means that 
a tape inusl be moved vertically above file drive to remove 
ii. n i anno! move down through ihe drive mechanism. This 
allows just over 10 mm from the front of any tape to the 
autoloader front panel. This <-m (figuration also places the 
drive at Ihe rear iiotiom of the autoloader so thai access to 
other tapes is from above the drive. 

This configuration does have some benefits. The drive con- 
nectors and option swihhes on the rear and bottom are di- 
rectly accessible al Ihe exterior of the autoloader. Thermally 
this is also ihe best arrangement because the drive base fe 
exposed to the exterior air, The drive base is an important 
heat dissipation area just below the main controller printed 
eireuit assembly. Finally, for integration and repair we wn, 
aide to design liu autoloader to accepl the drive with a sim- 
ple bracket arrangement and a single a innecting cable, 

Tlie changer mechanism 1 controller printed circuil assembly. 

til [azine, and door and front panel parts have to fit in the 
rest of the available space, At this poinl we cheeked again 



Autoloader Control Electronics 

loader control electronics were designed with the -g the 

anisni and firnrwars elements v. rwenteefrr. :ost 

Tne main contntfier primed circuit assefnfcly is a through-note de shape 

space envelope k assembly 

zed directly from the mechanical CAD modet bec^ 
Control of r • 
on-board or^time-pnxr 
pins bfimg a 

by the microcontroller control the dc motors and their integral gearr. 
level motor current sensing is used to detect mechanical jams or exce 
loading, The tour motors and the piekf e?ed from the 12V supply 

available in 5 V*- inch peripheral slats. 

The state of the mechanism is determined by optical m motion, a 

mechanical par has a nb that is made i jugh slotted optical switches 

The rib has slots at datum positions in the motion that are detected by the opto- 
switch. The width of each slot is calculated to reflect the mechanical tolerance of 
ihe particular motion so that the firmware can guarantee a particular mecta 

position as long as the optical switch is open An important philosophy here was 
to position each slotted r>b icomb'i at the "point of action" (the farthest point from 
the motor drive) so that backlash does not compromise the accuracy of the position 

detection 

By using relatively large (and inexpensive) motor drive ICs operating well w li 

Lheir thermal specifications and mounting the printed circuit assembly vertically for 
optimum convection cooling, thermal problems were avoided Far the picking 
action, an oversized solenoid is operated conservatively so that it does not get too 
hot. The solenoid delivers a relatively large force for the picker fingeis but for short 
durations (Jess than two seconds). 

The troni-panel printed circuit assembly is connected to the main controller 
printed circuit assembly by a flexible circuit Mounted on the front-panel printed 
circuit assembly are the three front-panel switches, the door open optoswitch, 
three LEDs, and the LCD. The LCD is a custom design procured with a standard 
driver IC on its flexible circuit, which is soldered to the front-panel printed circuit 
assembly All oi these components were physically modeled in the HP ME30 CAD 
system to integrate the electrical and mechanical designs, 

An important design goal was ease of access to the printed circuit assembly since 
• ware is stored in an DTP device that must be replaced if firmware upgrades 
are necessary To this end the board is fully Conner. if wfzsd and fixed by a single 
screw. No adjustments or calibrations to the printed circuit assembly are needed, 
so complete printed circuit assemblies can be swapped in if necessary The layout 
printed circuit board is heavily influenced by the flexible circuit designs and 
a lot of time in the early stages of the project was spent on the topography of the 
flexible circuits, their routing, and the effect of the positions and direction of entry 
on the punted circuit assembly layout In particular tn keep the cost of the flexible 
circuits as low as possible they were all designed as single-sided circuits This 
dictated pin ordering on the printed circuit assembly, which also needed to have 
minimum layers to keep ti low in cost The final printed circuit assembly has 
four layers including power and ground planes covering 90% of the board area 
There are four flexible circuits connecting the motions and the front-panel printed 
circuit assembly Their physical layouts were modeled on the HP ME30 system and 
also ustng paper mock-ups to check for control of their positions when moving, as 
well as track layout, 

Greg K Trezise 
Development Engineer 
Computer Peripherals Bristol 



whether we could exceed the form factor, and were again 
asked to too* inward rather than outward 

Ideas were* tried in outline form to maximise the number ui 
ran ride's wiih the simples! mechanism It quickly became 

ctear Lhal the size i <i ihi 1 I 'I >S cartridge toposed limitations 
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that dictated the capacity and mechanism design. For exam- 
ple, even wi(h minimal thicknesses in between, there is only 
room lor three can ridges above the drive. To achieve a ca- 
pacity of four with a simpler mechanism the carl ridges 
would have to move up and down in from of the drive, hui 
this violated the form factor. 

i sing i iily mockupa and cartridges, we arrived at the possi- 
bility of rotating the column of three tapes above the drive. 
This accommodated six can ridges and would make lis the 
market leader in capacity. There is jusl space, but how could 
it be implemented? fhe vertical heighl of I tie components 
had to be pared down to the minimum. For example, there is 
LB mm between cartridges, 1 mm for a shelf in I he maga- 
zine, and 0.5 mm clearance (all dimensions nominal). The 
volume swept by the six tapes rotating is very large, taking 
up about half the height of I he autoloader and most of the 
width, leaving only about 8 mm on each side. We decided 
thai the changer mechanism would have to occupy some of 
the swept volume when the tapes were not rotating. 

We used the HP ME30 mechanical CAD software to plan our 
air space and implement the concept At (his point three 
mechanical engineers developed the design, sharing I he 
same file system and conventions so thai we could easily 
load the subassemblies of our colleagues to check for 
clashes and interfaces 

Autoloader Design 

The autoloader can be broken into several physical sub- 
assemblies, as follows: 

i Magazine 

■ Mechanism motions — X, Y T Z T R 
Front panel and user interface 
Control electronics and moi 
Mechanism firmware 
Drive firmware, SCSI interface, and link to the mechanism. 

Magazine. The magazine is made from polycarbonate plastic 
moldings (see Fig. 2). It is simply a com airier for the six 
cartridges, three on each end. The main molding is a box 
structure into which some shelves are fixed. 




The thin ( 1 nimj wall sections and usability features made 
this an extremely challenging design Required features 
were retention of the cartridges and acceptance of the cor- 
rect orientation only. In other words, you can only put the 
cartridges into die magazine in the correct way, and then 

I bey stay in, even when you shake them by hand or apply 
shock and vibration to the unit. The cartridges were iu>i 
designed with these features for autoloader use, so we had 
to be creative. In addition there are regulatory 7 requirements 

I I 'LU4-V2 Jlame resistance) and a need for reasonable robust- 
ness, thai is I he cartridges should not be damaged if the 
magazine is dropped on the floor The magazine also has 
areas for a label and indications to help ease of use. There is 
a gear form along one side for automatic loading. The maga- 
zine is shaped so that it can only he inserted the correct way 
into the autoloader. 

A semi i ransparenl polypropylene library case is supplied 
with the magazine. This allows the user to store the maga- 
zine neatly with some protection, It is similar to the library 
cases for commercial videotapes. 

X Motion, Looking from the left side of the unit die X moi it »n 
moves horizontally (front to back) in the autoloader (see 
Fig. 3), This motion moves the cartridge horizontally. The 

I Luri tinned on page TBI 




Carousel and 
Magazine 




Fig, 2, The six-cartridge magazine is designed to be handled like 
one large tape eartridi-.. 



Fig- 3. j al Interior teyattt i .J' the HP C1553A autoloader, (h i Motions 
of the cartridge changing mechanism. 



1 4 December I ytu H vwl e t t -Packard Journal 



)Copr. 1949-1998 Hewlett-Packard Co. 



Autoloader Firmware Design 



When the HP CI S3A 00S-2 autoloader w a :ne of the primary goals 

m add the autoloader mechanism to a standard DDS drive with no hardware 

■■^drtveano minimum firrnwa-. 
r -:iu'e allows the autoloader mechanism to be i noependerit of drive ha 
and to oe used w ,-e products 

roduct line was not designed to be . 
auto requirement for a fowcost autofoao-: was 

to add an autoloader to ' 

r. of the drive/autoloader interface, both hardwar- 
no hardware changes to the drive 

* Addition of the loader command set to the drive firmware 

* Design of the autoloader electronics and * -.able the required 
communications with the drive 

Drive/Autoloader Interface 

Since the drive had not been designed with the intention of interfacing to an 

autoloader, there was very little hardware availabte to create an interface v I 

autoloader mechanism It was decided that a part mat was used for debugging 
purposes in manufacturing test could be used to communicate with the autoloader, 

since it had no use outside the manufacturing line. 

The port has four data fines and a single address line along with the required 
handshake lines for the drive's B80OO processor. This allows a total of four regis- 
ters, two write-on Ey and two read-on ly It was decided that these should be 8 bit 
registers accessed by two successive 4 -hit operations The four registers are the 
drive status register, the autoloader status register, the drive autoloader command 
register, and the autoloader drive report register 

Two registers are used as a command report mechanism to allow the drive to send 
commands to the autoloader This is the basis lor The control of the autoloader. 
When the drive receives an SCSI command that requires autoloader operation it 
writes ths appropriate single-byte command code into the drive autoloader com- 
mand register as two four-hit writes When The autoloader has completed the opera- 
tion it places the single-byte report in the autoloader drive report ragisfSf 
assarts 8J1 interrtipl siynal to the drive to indicate that the register should be read 



Commands that require parameters are preceded by a push parameter command 
e-byte command that has the top hit set Ail other commands have the 
g seven bits to be pushed onto a para- 
sramete? commands allow mora than seven bits to be 
pushed 

for handling the front 

alone drive's, rt is accessed via the autoloader pre 

processor has the respc he autotaader what to do, 1 he front- 

-tsJS 

register This allows maximum flexibility Of ope ration 

e the usabii I fed to use a character - 

based LCD display to give messages to the operator Since most of the 

information comes from the drive, the drive status register rs used to pass status 
codes to the autoloader to display status messages on the display The text for the 
messages is stared m the autoloader processor ROM While it would have been 
more flexible to store the messages in the drive, there was insufficient spa 

Drive Firmware Architecture 

The changes required to the dnve firmware to implement The drive/autoloader 

interface relate to two distinct areas The architecture of the firmware for the 

autoloader is shown in Fig i 

First, the normal front-pane) handling task within the firmware is replaced bv a 
new version, which communicates drive status to the autoloader This receives 
status information from both the SCSI task and the drive task on the drive. This 
status information is passed over the drive/autoloader interface rather than being 
displayed on the drive front panel The SCSI task is changed to read the buttons 
B new front panel as well as Ihe eject button on the drive The drive eject 
button is left active so that a tape can still be recovered from a drive in an auto- 
loader even if the autoloader hardware is not working. 

Secondly, the SCSI task required the addition of the functionality to handle the 
SCSI medium changer command set. This involved adding new functionality to the 
task to interpret a new class of commands and pass them on to the autoloader 
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fig. 1. Autoloader firmware ammrecrure. 
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Cam Tracks 



mechanism. Parsing the commands on the drive allows the drive to remasn in 
control of the whole autoJoarJer and minimizes the risfc of confhciing commands 
going to the drive and autoloader, It also avoids duplicating the software to parse 
SCSI commands for both the drive and the autoloader 

Autoloader Firmware Architecture 

The autoloader firmware consists of three distinct functions These are commoni- 
■ ■aling over the interface to the drive, handling the dispiay, and controlling the 
autoloader mechanism. 

These three functions are implemented in three separate tasks running in a round- 
robin fashion with a 1-ms time slice for each function. This made development ol 
the software easier and allowed The separate functions to be implemented with 
minimal risk of interference with one another 

To save hardware costs, the dnve/auto loader interface re g Esters are not imple- 
mented as hardware latches. Instead, the I/O lines from the drive are wired dirtily 
into the ports ol the H8/32B microcontroller used to control the autoloader mecha- 
nism, The H8 has a set of internal memory locations that mirror the imaginary 
hardware registers. When the select line from the 68000 is asserted, indicating an 
access to the drive/autoloader interface registers, tms causes an interrupt to the 
H8. The H8 reads its I/O lines and handshakes the data to or from the 68000 This 
gives the appearance to the 68000 of slow hardware latches. The tasks running on 
the H8 merely need to access the internal memory locations as if they were the 
registers 

The drive status register is treated slightly differently from the other registers in 
the drive/autoloader interface Because the drive can send repeated status values 
to this register fester than the display task on the H8 can read them, the values 
are queued within the HE to betead in sequence. This ensures that an important 
status code is not lost behind a less important one. In addition, certain status 
codes cause flags to be set within the H8 that determine whether the drive is in a 
certain stare. This allows tracking of the state of the drive. 

Mark Simms 
Development Engineer 
Computer Peripherals Bristol 



cartridge 1 is gripped by metal fingers (mounted on a picker 
arm) on an edge near where a hitman grips the cartridge, 
The fingers are sprung shut gripping a cartridge in case of a 
power failure, and are opened by a solenoid* The fingers are 
mounted on an arm, which pushes and palls the cartridge. 
The arm can pull a cartridge out of the magazine and push il 
into die drive. The picker ami is moved by a belt, which is 
driven by a dc gear motor 

The cartridge is not designed for manipulation by a mecha- 
nism, so the choice of features that were suitable for grip- 
ping and aligmnent was limited. The obvious edges were not 
specified in the cartridge standard, and it took two years to 
have some of these features added to the standard. 

V Motion. The V motion moves the cartridge and picker arm 
up and down. The picker arm is mounted on a platform that 
is lifted or lowered by two cams. The picker arm runs on 
a shaft, allowing the X motion. The shaft and the other X- 
motion parts including the gear motor and belt are all 
mounted on the platform, Connections are made to these 
parts by a flexible circuit. The platform has three pins, one 
on the left and two on the right, which project out the sides 
(looking from the front of the unit) into cams, one on each 
side of the unit, The pins run in tracks that resemble escala- 
tor shapes* that is, they have 50-degree slopes with horizontal 
portioas. The pins can only move vertically because they also 
run in slots in metal plates. The cams with the shaped slots 
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Fig. 4. Y-motion c#tfl cfce$gEi r;i i Vii-w nf thr V cartas from Via.' JY. uii 
top right, (b) View of the Y cams from the front top left. 

move backwards and forwards and drive the pins and the 
platform up and down (see Fig. 4). Both cams are driven by 
one dc gear motor The one on the right has a molded rack 
and is driven directly by a gear on the gear motor. The left 
cm n is connected by a lever across the bottom front of the 
unit to the right cam, and is driven by the same V <>ear 
motor. This earn arrangement tolerates mace mate position- 
ing of the Y gear motor and cams, The height of the earn 
components themselves determines the height accuracy of 
the platform, which early ealculat it >ns showed is adequate, 
The pins can be anywhere on the horizontal portions of the 
cam tracks, which arc about 5-mm. long. The Hat plate ar- 
rangement of the cams and tracks fits neatly into the unit on 
either side of the platform. The left cam extends into the 
magazine rotation area making extra use of the space when 
the magazine is not rotating. 

R Motion. The R motion is the rotation of the magazine. Hits is 
achieved by a large disk in the top of the unit. The magazine 
sits on top of the drive. The usual drive lid (top) is replaced 
with one that has the front edge cut away to allow the car- 
tridge to be lifted straight up with the 1 1 -mm overlap, The 
rotating disk in the top of the unit has two moldings attached 
to it that hang down on either side of the magazine, allowing 
it to be located and turned around, Originalh the rotating 
disk in the top of the unit was going to be inside the unit. 
However, because of the extreme vertical spare problems. 
die disk is actually part of the exterior surface of the unit. 
The disk rotates ISO degrees and is driven by a dc gear motor 
through a clutch. The clutch allows me disk to be driven into 
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an end stop for accuracy while preven t in g damage to the 
gear motor, which wa* found in early prut- itypes. The dutch 
is a custom design and drives a gear form on the disk. 

Z Motion, The Z motion is the movement of the magazine in 
and out of the autoloader. The magazine has a large rack 
(gear form) on one side. This engages with a gear in the unit, 
which is driven, tlirough a custom clutch, by the Z dc gear 
motor. A microswitch (Z switch i activated by a rocker arm 
indicates when a magazine has been inserted by the user 
The insert and eject mechanism (Z motion) is deliberately 
designed to mimic the familiar h- i tm ■ Wite i y pe of 

at Iser tests showed that this action was familiar and 
Intuitive. The action of the user is to push the magazine into 
the autoloader tlirough the door, which is sprung shut. The Z 
switch detects the magazine and the Z gear motor stalls. 
When the magazine is pushed a little farther the gear engages 
and pulls the magazine from the user, i in entry the magazine 
compresses a spring-loaded pusher arm, which is used on 
ejection. The Z switch also detects when the magazine has 
reached the fully home posit ion , thai is, fully into the unit. I Ml 

inn the Z gear motor pushes the magazine out tlirough 
the opened door As the gear disengages, the sprung pusher 
completes the ejection. The magazine is caught by a small 
sprung plastic part to ensure a consistent eject distance. The 
distance is over 22 mm, which allows handicapped users to 
grip azid remove the magazine. 

The lid assembly, which contains the R and Z motions, was 
one of the later subassemblies designed and proved very 
difficult to finalize. The physical space restrictions and the 
desire to get the right feel lor the user meant that several 
iterations oi design had to be pro totyped and tested. 

Front Panel. The front panel assembly provides the controls 
(three buttons), displays, and door (see Fig. 5). A printed 
eircuil board mounted behind the front-panel plastic mold- 
ing has i he display and switch components on it. * )nce again 
space was at premium and the whole assembly had to be 
thin to miss other mechanism parts, The layout Avas deter- 
mined by the user tests and the position of the door. The 
door is centra] in the upper portion. The entry has a keying 

feature so iiuu the magazine cj I to inserted the wrong 

way. ( 'oml »iiied with the magazine features, this means thai 
the user is guided mio correctly inserting the cartridges and 
prevented &0IH making mistakes. This means I hut the cor- 
rect orientation of die cartridge is ensured when it arrives 
inside die autoloader. This is not always the case in other 
autoloader systems, which have to check ihe orientation. 

The door opens inwards and is sprung shui . bur for maga- 
zine ejection the door must be opened by the unit to allow 
the magazine to eject. The door is locked when a magazine 
is inside the unit to prevent tampering or injury to the user. 
It is unlocked vs lien there is no magazine inside to allow the 
user to Insert one. The door is pushed open and locked by 
the movement of the left-hand cam. The cam travels are 
ex i ended to allow this operation, At the normal resling Y 
height [bottom oi travel in from of the tape drive), the cams 
move farther to Unlock the door, I hen fart her To push open 
the door This allows the extra ban Hon vviih no extra gear 
motor or mechanism. An optoswitch sensor detects whether 
the door is open; ii^ main purpose is for safety, mi thai ihe 
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Fig. 5. Fn.ni panel layout 

unit can I I in ease of a faulty lock, in l his case, the 

unit Hill display an error message, "Close Door/ and wait. 

The appearance and position of the front-panel displays and 

controls were determined by ihe indnsinal designer within 
the mechanical design limitations and were heavily influ- 
enced by the user lesi rcsulls. Hark on, some tnockups were 
tested iiet ai isc there is potentially a !«>l of information that 
could be displayed lo the user, such as error messages and 
many status messages, about 60 total. The most basic- button 
and the one that all users require is the Eject butt oil This 
was made large and obvious, the shape making it look push- 
able SO that minimum or no text, is needed for users to 
choose it. The seennd button selects a starting tape, of the 
ones loaded, and the final button starts a manual backup. 
Alternatively, the unit can be controlled by scsi commands 
from the host computer. 

The displays are grouped into iwo ivpes; those giving overall 
slants thai can lie seen Ft a distance, such as fcflfij backing 
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Network Backup with the HP C1553A DDS Autoloader 



The four main applications for the HP CI 553A autoloader described in the 
accompanying article are: 

• Single large backup 

» Centralized network backup 

• Fully automated backup 

• Near- fine data storage. 

The backup of a large amount of data in a single session is a clear application for 
the autoloader. Today there are many servers with a djsk capacity exceeding that 
of a single DDS-2 cartridge, which is typically 8 gigabytes with 2:1 data compres- 
sion The system administrator with a single tape drive must either manually 
insert new tapes into the drive when doing full backups, or must settle for incre- 
mental backups thai only back up the data that has changed since the fast full 
backup, These two options present some difficulties Backups are typically carried 
out at night when server use is lower, so tape changing is inconvenient at best A 
restore based on an incremental backup routine can be complicated since it will 
involve using several unrelated tapes. The autoloader, with its six cartridges, 
enables the system administrator to protect up to 4B gigabytes of data in one 
single unattended session, 

Most of today's local area networks consist of several servers and many clients. 
Centralized network backup involves backing up all servers and clients across the 
network onto one high-capacity drive such as the autoloader: This is a cheaper 
alternative to having a separate tape drive on each server. Other benefits include 
having only one tape drive and one software package to administer and enhance 
security by having all removable rjata in one location, which can be physically 
secured. This is the same rationale that has been employed for centralizing net- 
work printing on one high-duty-cycle printer For additional flexibility each of the 
the autoloader's six cartridges can he configured to hold data from a specific 
source. For example, each server can be backed up to its own cartridge and all 
clients to one of the other cartridges. Alternatively, all servers and clients on a 
segment of the network can be backed up to a specif ic cartridge. The exact choice 
will depend on restore and disaster recovery considerations. 



Fully automated backup relieves the busy system administrator from another task 
previously taken for granted m the days of central mainframes tape rotation 
Methods such as "grandf ether-father- son" and "tower of Hanoi" were developed 
to prevent overuse and wear out of media and to make available several differently 
aged versions of data when restoring. These methods involve backing up to a 
different cartridge every day for the system administrator with a single tape drive 
this means manually changing the tape in the drive every day If for some reason 
this does not happen most software packages will abort the backup, meaning that 
the system is unprotected. Ivlore significant, when the time comes for a restore, 
the system administrator must be on hand to retrieve the correct cartridge from 
secure storage and manually load it into the drive. These tasks can now be auto- 
mated by making use of the autoloader's multiple -cartridge capacity A simple 
routine with five data cartridges and a cleaning cartridge could be configured to 
perform a full backup every weekday to a new tape. This weekly cycle could be 
repeated over an extended period of time. A routine giving a longer file history 
would involve performing a full backup on the first day of the week, fallowed by 
daily incremental backups la the same tape The magazine would then provide 
five weeks of protection for a server of up to five gigabytes. Using a tower of 
Hanoi rotation scheme, sixteen weeks of protection can be achieved with a single 
magazine In all cases, the only manual intervention would be periodic magazine 
rotation to a fireproof safe or off site location, Restores no longer need ld involve 
the system administrator, either. With all of the cartridges available by random 
access in the magazine, the backup software can give users the ability to restore 
their own files with overall access rights controlled by the system administrator 

Prolonged operation of tape drives without any tape head cleaning can result in a 
media warning that causes the backup software to abort the backup. This need 
not be the case with the DOS -2 drive, which has a has a self -diagnostic capability 
that senses the write error rate When this increases beyond a conservative 
threshold, the drive sends a message to the backup software, which can respond 
with the initiation of a head cleaning cycle using the cleaning cartridge included in 
the magazine. This will typically occur every twenty-five hours of use and ensures 
a long period of error-free operation without system administrator intervention, 



up, or fault condition, and those giving further detailed infor- 
mation that is required when the user is near the unit, such as 
"Insert Mag* or "Clean Me." A custom LCD was selected for 
the detailed information, the custom icons and layout en- 
abling a lot of information to be conveyed at a glance with- 
out long text messages, Ten characters of text are available 
to display messages (see Fig. 6), The printed icons beside 
the three buttons and three LEDs were also developed and 
tested for intuitive use by users and to avoid any text that 
would require localization. The exception to this is thai I tie 
word l 'Hject" was required by the English speakers tested 
because the universal eject icon, seen on almost every VCR 
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Fig. 6. Liquid crysLal display layout. 



arid cassette player, was not recognized! The word "Eject" is 
ac cep t ab le i nl e in a I i o n ally. 

Control Electronics. This development effort is described in 
"Autoloader Control Electronics" on page 13; 

Mechanism and Drive Firmware. This development effort is 
described in "Autoloader Firmwp^ Design" on page 15, 

Mechanical Design Methods 

ME30, HP's 31) computer-aided design tool, was used by the 
mechanical and manufacturing engineers. It was run on HP 
9000 Series 700 workstations rliyi had a common disk 
mounted with directories struct tired and named like the 
product subassemblies. The designer's were responsible for 
maintaining the latest revision of their parts in these shared 
areas, and for providing a macro that would simply load aU 
the subassembly parts, The motors, the flexible circuits, and 
the main components on the controller printed circuit as- 
sembly were all modeled. Thus the latest design was avail- 
able to the designer's for cross-checking, and to the procure- 
ment and manufacturing engineers for process planning HP 
ME30 proved very valuable at speeding up the cheeking and 
success of prototype assembly builds. Better visualization 
allowed the designers to spot problems early, thereby avoid- 
ing embarrassing problems on prototype builds. On one oc- 
casion, we discovered Thai vw were about to design a gear 
motor assembly through the center of the 118 microprocessor! 
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: moving appl ication fc* age devices 

based : jftware known as 

Storage Management software The size of hard dtsk mass storage on servers is 
mere;: m Today's average network serve? has a disk capacity of 9 

gigat "0 40 gigabytes wrtfun liie next five years 

Faces a constants 

s Tne reason for not ac_ 

medium, but 



-nt seeing oaia thar» actually reading it The limitation can be reduced by 
-iing" ttie data to be read over sevara one or more disks are 

i data one of the otlw disks can be readmg data. This spanning can usually 
be implemented in the operating system but is more common! y implemented in 
me form of a redundant array of inexpensive disks (known as a RAID 
-'SB a dedicated contra Ife and 

• • 
jpdatafror 5iay 



:er of 

u se pattern of fi I es on a typj cat server snows that 
some current fifes are accessed frequency, bur that the majority are older - 
used infrequently. Hierarchical Storage Management software track? 

frequently use jwer-cost storage me- 

dmm, Although the file is stored on another device, a phantom file of 25*0 size is 
left : n the original : far as the user is concerned the file is still present 

When access is re:; ■ rarchical Storage Management software retrieves 

it automatically The small delay in retrieving the file from the slower device is 
acceptable on an occasional basis All of trie activity is transparent 10 the users. 
who effectively see a virtually unJrmited amount of disk space The data migration 
is triggered at typically 8Q% of disk capacity. The system administrator therefore 
neve- needs to be concerned about running out of disk space The auto loader with 
its six cartridges can provide up to 48 gigabytes nf near-line data storage at a 
fraction of the equivalent hard disk storage cost. 

Performance Considerations 

The autoloader's large capacity is well-matched by the DDS-2 drives high data 
transfer rate However, backup is a resource intensive operation mat uses all uf 
the components of the computer and network, not just the tape drive Careful 
selection of all nf the hardware is required to balance the throughput and ensure 
that there are no bottlenecks The exact configuration will depend on the type of 
backup being performed. 

For server-based backup, lha limiting component is typically the hard disk drive. 
Backup involves randomly accessing all files on the bard disk. The disk can spend 



rk backup, the limiting component is typofh 
rrmsi popular network topology «s Ethernet, operating at a bandwidth of 10 
megabits per second Dot - the data must t r " : 

.vith ail of the disk 1 jits in most cases in a transfer 

-la If of the maximum !he DDS-2 drive can achieve Tnis can be reduced 
jit of traffic on the network is high enough to result rn {jacket 
collisions, so backups should be run at night when traffic is low, To achieve higher 
transfer rates over the network, faster topologies must he used FDDl over hher- 
optic cable and 100 Base-VG both operate at 100 megabits per second, ten times 
faster than Ethernet Implementation of these technologies is becoming more 
widespread for reasons other than backup, such as multimedia and video. For 
existing installations it is not necessary to recable the entire network The majority 
of data transferred will be from server to server so these can be connected together 
with a dedicated high-speed backbone. This will result in a backup speed close to 
the DDS-2 drive's maximum 

When using intelligent data management software, an apparent increase in per- 
formance can he seen. This is because the infrequently accessed files, after hav- 
ing been backed up several times, are considered stable and are no longer backed 
up, A full backup therefore involves fewer files and can be completed in a shorter 
time Th^s performance gain js achieved with software without any changes to the 
hardware. 

Micnael G. Bemayne 

■■; eg! Marketing Engineer 
Mass Storage Europe 



Ah hough valuable, fchs latest IIP mechanical CAD software 
does not fully simulate all the mechanical motions. In this 

r[ it is less mature than EE CAD, So the traditional 
design, build, test, redesign cycle is still the major way l« ■» 
achieve reliability improvements in the design. Anything 
dial can be done 10 shorten this cycle, rapid prototyping foi 
example, can save weeks or months t>|" lime to market. The 
:1D models alio wed as- to us thelatesi fast protDtyptagtHJetti- 
eds, deluding stereo lithography andCNC milling of parts. 

Design Margin Analysis 

Because of the desire to prove as much Of the design as pos- 
sible before commitment to tooling, we adopted an unusual 
approach to (he mechanical tolerances. T>]iic alh designers 
will approach ke\ areas and perform a tolerance analysis. 
They will add up flie tolerances for the parts using data ihai 
rh«\ hope is representative of the production p:u 1 Because 
of the lack of space, interdependencj' of all the subassem- 
blies, and Sfimplj pressure of work on the designers, we de- 
cided to adopt another approach. A consultant from Crunfield 
Institute of Technology, one of the leading teaching and con- 
sultancy groups in nianufaeliiriiiu technology in the IK, w;^ 
enlisted 10 help analyze ilu' tolerances. We started from the 

Outside in, deciding on the key areas of functionality, ll 

building nc spreadsheets of the systems with the tolerances 
< to procurement engineers provided capability study data 
for the manufacturing processes of similar parts 



Starting otri with simple arithmetic, we huilt this analysis 
into a design margin index. 1 The managers and designers 
were Mien able lo have a single number for the "goodness" 
Of the design in each of six key areas. This was obtained by 
the root -sum-' >f-sijuares (RSS) method Of Calculating loler- 

ances. J The squares of the tolerances are ill added, and then 
1 1 square rooi of tin- mhu gives the variance of the assem- 
bly, If we had simplj taleen worst-case tolerances the design 
would not have worked because the worst-ease numbers 
were too targe. Tile KSS method assumes that the pails have 
a typical 1 Gaussian distribution of sixes. Statistically, taking 
file RSS onij excludes Q*2?M oftfoe possible cases. This was 
not considered completely satisfactory, so our goal whs to 
have L6 tames the Hss Bgure as the minimum design crite- 
rion for each key area. A simple scoring method of compar- 
ing the actual RSS figure for the ke\ area \uili the goal of 
1.5RSS gave us the "goodness" Bgure, Because the key areas 
in noi independent, this allowed us to view die overall ca- 
pability of the design and prevented conflicts such as im- 
provements hy a designer in one area increasing margin at 

die expense of another key are& 

The use of a consultant to check the design and The use of 
the design margin index strengthened im execution of the 
mechanical design, forcing us to change the design mi 

I'm HJiirtimi processes of some pai ts 
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A Change of Direction 

As the design approached completion and we unv ready to 
start iJiothK-rioii prototypes in manu&cturifig, the division 
reassessed the manularurri i \g:g®t&ft fgy. It was dear that the 
product would consume mure resourees ihan the division 
was willing to commit, The Increase in volumes of the 
DDS-1 products and the launch of the DDS-2 drive at nearly 
the same mm ■ m mid cause a bulge in resource requirements. 
The decision wBS made to ftnd a partner lo manufacture die 
autoloader mechanism, while HP supplied (he DUS-2 drive. 

Biim-und DateuTechnik (BUT) GmBII was selected and 
from Novemher 11)1)2 worked closely with us to take the 
autoloader into manufacturing HOT was selected for their 
manufacturing expertise and quality in producing similar 
products, including paper sheet feeders Tor printers and 
another autoloader. The partnership has proved extremely 
successful. Their engineers have looked critically ai the de- 
sign and improved it. They have developed it and taken it 
successfully into manufacturing. HP was able to redeploy 
people on either projects, leaving only a core Team to work 
with HOT. 

Applications 

lb ensure the availability of software solutions that fully 
support the automation features of the HP G165$A* IIP has 
developed the LABS [Low- Admin Backup ini St ■* vers} stan- 
dard guidelines for software developers. The LARS guidelines 
i I* line a set of software attributes that virtually eliminate 
human operator invoh enienl in the backup process. The 
LIP SureStoreTape 1200e prndnn is available as a bundle 
with LABS software developed by Palindrome Corporation. 
In addition, several other solutions are available fur differ- 
ent operating systems, such as Cheyenne ARCSKRVH and 
Palindrome Backup Director for Novell networks, Arcada 
Backup Exec Tor Windows NT and Legato Net Worker tor 
I -NIX '" systems mid Nu\ell 

The autoloader can work in two ways, depending on the 
application software: random mode or sequential mode, in 
random mode the sofl ware issues SCSI medium changer 
i umi Hands to load a specific call ridge number. The software 
therefore has complete control uver the operation. In se- 
quential mode die user starts the backup from the chosen 



cartridge, say cartridge 1, and the hosi writes untu the tape 
is full. The host then issues an SCSI unload command and 
I he autoloader replaces Hie cartridge with ihe next one auto- 
matically. This allows easier integration into older systems 
I hat do not support llu- SCSI medium changer command set. 

Seepage 18 for more about network backup applications. 
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We must give a special mention to the BDT engineers and 
production personnel who look our basic design, criticized 
and improved j|. They put in nun b hard effort mid good faith 
to get the product into mmuifacturing. 
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Automatic State Table Generation 



The HP C1553A DDS tape autoloader requires a complex sequence of 
simple operations to carry out mechanical retries. These sequences are 
defined in tables. Cadre s Teamwork was used for input and an automatic 
tool was used to generate the tables to go in ROM . 

by Mark J. Si in ins 



The autoloader firmware for the HP G 1">>A digital audi* i 
ta| ii' autoloader was written in the C programming languag< i 
to run on a Hitachi HS/325 professor. This process H is an 
embedded system microcontroller with built in ROM, RAM. 
l/U pons timers, and serial ports. This allows a very low- 
cost implementation of the autoehanger coul roller in which 
m6St bf the font lions can be earned 0111 in ;i -in I* chip. 
However, the largest ROM size available on the H8 series of 
I >rot essors was 32 K bytes. This means that the complex 
retry algorithms required for controlling such a mechanical 
device needed to be implemented in as compact a manner 
as possible. 

Qur laboratory has a large amount of experience in producing 
table-driven systems. All of our products have had some f< inn 
of table-driven control structures in some pan of their ilnii- 
ware However, experience had shown thai there nin be 
severe problems maintaining table-driven cade because of 
the difficulty of 1 1 lain I ah ting I he tables. This derives from the 
lack of readability of software written in C or assembly lan- 
guage thai merely defines the contents of data structures. A 
lot of documentation needs to be added to the source code 
hi explain the meaning of the entries. If this is noi main- 
tained, then the declarations rapidly become nun adable. 
This greatly increases both the lime needed n> implement 
changes and the risk of errors. 

The designers of the III* 9146A cattrktge tape drive and the 
IIP 35470A DDS tape drive attempted to Improve this situs 
tion by defining state machine languages that can he trans- 
lated infu < source code automatically These languages 
offered powerful constructs for denning the tables in terms 

of Stan- mnchmes Th<- software would remain in one slate 
until an event was detected. Then a set of act ions would be 
carried out and a new slate entered. This approach made the 
table definition much more readable than the basic data 
declarations and greatly alleviated the maintenance problems. 
However* the state machine languages suffered from many 
of 1 fe 1 problems that arc characteristic of "unsmienired" 
programming techniques There was no observable 1 How in 
the source code since transitions were permitted between 
any two states. This made it \rv\ difficult to follow the BOT 
of the program and determine what sequence of actions had 
occurred. 

lb aid In documenting these state machines, the Teamwork 
structured analysis tool from Cadre Technologies was 
adopted "his allowed the initial problem analysis to be < ;n 
ried <nn iiiuphically. A state transition diagram was produced 



to document the desired solutiot . 1 1. This was then 

implemented using the state machine 1 language. However, as 
1 he state machine language description was modified, the 
diagram gradually became more and more out of date and 

was updated periodically. This meant that while I he diagram 
could be used to gain an initial familiarity with the softwan 
it could never be guaranteed to be completely accural «■ 

With the HPC15S3A autoloader, these problems became 
more serious. The state Tables were to be used very exten- 
sively for mechanical control. Also, there was a very strong 
need to communicate the control algorithms to mechanical 
engineers and the product test team. Tins reijuired that good 
ace mate documentation be available to all within the divi- 
sion. It Wffi ffilt thai any manual syslem for maintaining such 
documentation would prove unusable in real situations. .As a 
result, a decision was made to generate the state tables di- 
rectly I mm the Teamwork diagrams. This would ensure 
that the diagrams were always accurate reflections of the 
software. 

Design Implications 

Analysis of the HP C1553A motor control software showed 
that the software divides into two major sections. The first 
is a number of routines lhat handle the low I eve] control of 
the tuectiani sin These routines control the motors and sole 
noids, tead sensors, and track the position of the mecha- 
nism. They Hack control information and map that Onto rhe 
control signals required to operate the motors in the correct 
direction at the cdltecf pOWer level They debounce input 
readings and map them into mechanism position information. 
These 1 1 nitmcs are implemented in C and use global varial 
To interface with the rest of the software. The routines are 
called in sequence to carry our all the necessary interfacing 
to the mechanism 

The second section is the control sequencing. This contains 
a number Of state machines. Some of these are direct h 
linked to ill' 1 individual mechanism parts. Others sequence 
indi\ [dual mechanism Operations together in response to a 
single command These state machines interface with the 

level routines by meat is of the control information at id 
mechanism position global variables. 

Since several state machines are miming concurrently with 
the low ]e\ei routines, this cohcttiffencs must be reflected In 

I lie software. Kaoli State machine, win -n called, checks to 

see if a transition needs to be made. If not, control is returned 
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mc actio n="mc jammed" I 

mc aclion-"mc failed"/ 

mc action^ "mc reiract, picked 




moior .action^ "motor .action .|jowEr_on"/ 

mc s lotus ="nn .Error". 

M iiuin status^'lrue"; 

m c . map _ cartrid ge , h ej itj hl= "fa lse~ 

mc action="mc power on 2" 



2 recovering Z position 



mc aclion-"mc jammed" I 

mc flclipn=~rnc lailed'7 

mc aciion=~mc retract picker" 



in c_ action^ " mc su cecss " / 
r mc «tctinn- M mc power on V" 



3 dosing door 



|mc actron="me jammed " I 

mc actionVniG. larled ' I & mc. door . open/ 

mc, action- "mc retract picker" 



mc actio n="mc success"/ 

mc _ action^'mc _ refract, p i eke r" 



4 r ecu ven ng X p os 1 1 i on 



mc a client mc success 



13 wailing lor drive 



mc actinn= "<m: jammed - 1 

me .aciion^mcjailed"/ 

mc aclion="mc_relracl_picker'" 



retracting cartridge 



mc , ectiori-"mc _ jammed" I 

mc_ection= H mc_ laj led"/ 

IDS aclion="mc relracLiMckcr" 



motor d rive stat us v a 1 1 d & 

i.imolor drive status liirking="talse" & 
motor driye .status _prosen|="falsE') I 
I motor drive status lurk in rj-"\ rue & 
motoi drive status presem="lrue")|'/ 

roc_eclioni"mc_ recover carl ridge" 



5 recovering cartridge 



mc ac t nils-" m fj .success 



mi: K motion cartridge presenl="true & 
motor drive status present- ""line"/ 
molar \itivi: status Jurking="lruc" & 
mc actionem c put cartridge" 



mc . acii on= " mc . succ a ss" 



action^'mc jammed"! 
actiorc='meJ ailed'/ 
. action="mc_ retract, picker" 



16 checking cartridge 



14 putti ng c a midge back 



mc _ jt_rnotio n _ ca rtr< d ge present="true " & 
mntor drive status lurkniy— "ialse & 

in ii to r _. drjvc, slat u s..pr esenuT a Ise"'/ 

mc ..action = 'mc platform to drive" 



mc X motion cartridge present= "false" 
mqtor_dnve _status_lu rk i ng=' "f a I ae" St 

motor, drive status present="false'7 
mc ..acli cm=; " mc_ p tatf o rm jo .dri we " 



mc . acti on= "mc j a m med " I 

mc action= "mc I a tied 7 

mc action="mc retract picker" 



mc aclion= u mc success"/ 
mc.actio n^'mc _pl a tf orm _to _ drive" 



7 recoveri ng V position 



© 



© 



1 in-: X motion cartridge presenl= 'faise J ' & 

rn oto i dri ve status I urk i ng = ' tr u e " & 
motor drive status presenN"true'7 
mc _ actio o= " mc. pla tf orm _lo _ dri ye " 



mc_action="mc success" & 
motor dri ya _ status. I urk i ng="f else/ 

mc action- "mc unfoad cartridge" , 



rtK_action="mc_suecess' u & 
/motor drive status I [irking- "true" 



Ii recover cartridge el drive 



® 



2 : "it: Hr.:1iOii="mC SJiCCCSS" & 

mc cartridge he ight-"rnc 2'j height"/ 
m e c amidge „ he i ghK' mc J 4.Ji eight" : 
mc_ection-"mc platform to cartridge" 



m ciciir]n="nicjamined"l 

mc _a ction= "m c..f ai le d "/ 

mc action="mc lelraei picker" 



(mc_action="mc_success" I 

mc aclion="mc failed' l 

mc_action="mc Jammed") & 

mc. X motion cartridge preserpt-"false' 

mc_R_mntion_at_end^"truc'7 

mc slalus-"mc Error" 

mc_ m ap_sl atus= "true *' 

mc aclion- 'mc power on R" 



?9 power on R 



1 1mc_actioni"mc_success" I 
mc_ection-"mc jailed - I 

mc act to n^"m c . ja mm ad " ) & 

jme_R_motion_at end-"fahe" I 

mc X motion cartridge_present=" , rrpe7 

mc 5talus='no error" 

mc map statu s= "true": 

mc _ cartrid ge _ si rie=" mc_45G . side " ; 

mc action ="mc rotate magazine" 



mc actron="mc jammed"! 

mc actiDn^"mc„failed"/ 

mc action-"mc relrect picker" 



mc_acli on= " mc. succ ess"/ 

mc cartridge height="mc..3S height", 
, me_a cii on=i"mc_ platform to cartridge" 



mc. a clio n= " mc Jamm ed " I 

mc actiorN"mc failed"/ 

me_a ctio n= " mc_ retract _p icker" 



10 going up to push 



mc actionVmc success'/ 
mc.ectiuni-mc. se nse_ cartrid g e' 



T 1 push i ng i n cartridge 



|~rnc 


action="mc success" 


& 




mc 


cartridge height= 


mi: 


3G 


height"/ 


mc 


cartridge ..he ight= 


mc 


2b 


. height"; 


i rnc. 


action- 'mc platlo 


rm 


in 


:artridge" 



® 



retracting picker after 



mc actton="mc_jammed"l 

mc aclron-"mc larted"/ 

rnDlDi .action^ "motor, stains jammed" 



mc ection= "mc_success" & 

mc cartridge he ighl- 'mr. 14 height"/ 
, mc actionVmt platform..io_driye' 



TZ going back down 



mc action="mc_|ammad"l 
me action="mc failed"/ 
mc_actiq(i= <J mc_ratrect_picker'' 



mc action= "mc success"/ 
mc ..cartridge .side='mc_45G_side"j 
, mc_action="mc. rotate maoazine' 



. 



mc_.action="mc success"! 

mc actmn="iTn: |ammed"l 

mc action= " mc J a i led"/ 

motor action^ "motor status jammed" 



& recovering R position 



mc_aeti on= " mc ..succ ess"/ 

motor actions" oi olor _status_su tee ss" 



Fig. 1, Sli;' ^rain. 
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immediately. If a transition is needed, that transition is exe- 
cuted and control is returned. This ensures that all the state 
machines and low-level routines can be called in segue: 
thereby maintaining the required concurrency 

From this analysis, the following design criteria were derived 
for the state machine implementation: 

• The state machines must be able to respond to the values 
of mechanism position variables and executi rts 
according 

• The state machines mast i ^et mechanism cOlti 
variables when a transition occurs. 

• A timeout mechanism is required thai can handle times up 
to 30 s with a resolution of 1 ms. 

• Each state machine must execute al most one transition 
when execim n 

• Each transition must be executed as a complete unit to 
lessen the risk of data contention problems. 

• Tlte state machine implementation must use the minimum 
Space possible. 

» The ability to store a history of trace information must be 
provided for debugging purposes 

Interpreting Teamwork/RT 

The Teamwork/RT product provides a graphical state 

machine editor that has die following feal ores: 

• There is a set of states, each of which has a unique number 
and a unique name. 

■ There is an initial State, indicated by a single initial transition. 

• Transitions out of states may enter other states or may 
indicate that the state machine has exited 

• Transition information indicates the condition under which 
the transition occurs and may give actions that are to be 
carried out on that tnmsition. 

• Each transition condition is a logical expression consisting 
of a number of comparisons or variables with values. 

• Each transition action is an assignment of a value to a 
variable. 

The full syntax of this state machine description is sup- 
potted by the code generator tools. This gives a fairly rich 
design environment in which to work. It has the additional 
advantage that if the diagram is correct according to the 
Teamwork syntax checker, it should generate rode correctly 
and tluii code should compile. 

To parse the state machine diagrams, a program was written 
to access the Teamwork database. This retrieves ihe data 
struct arcs for a complete diagram, parses them, and genei 
ates the required code table. The program connects to the 
Teamwork database retrieves the state transition diagram, 
and follows the linked list of states. For each state, it Identi- 
fies each transition that exits thai slate. For each transition, 
it parses the associated text, and generates the required data 
Structures for its condition, actions, and next state. 

Finding the start and end states of a transition and finding 
the transition information that is hound in a given ira.n.sii ion 
involve^ tfee concept of an instance number. Each item in a 
Teamwork diagram is given a number to identify it. This 
number is unique across all items in the given diagram , 
whether an item is a text block, a transition, of a state 

The insTa.ui numbers nj ili<< initial and Qnal States and the 
text block associated with a given transition are stored in 



that transition's entry in the linked list of transitions. The 
state can be identified by searching through the linked list of 
states to find the one with the same instance number as in 
the transition entry. The text block holding the transition 
information can be identified by searching through the linked 

Text blocks ti> find the one with the same instance 
number. 

To increase the performance of the code generator, an a: 
of pointi blocks and states is set up at the start of 

the program. "The list of text blocks is and the 

in the array indexed by the instance number of a given 
block of text is set to point at that block of text. The list of 
states is searched and the entry in the array indexed by the 
instance number of a given state is set to point to that stale s 
entry. This allows the *tart state, end state, and text block 
associated with a given transition to be found by a single 
table look-up each. 

Parsing Transition Information 

The transition information associated with a transition con- 
sists of ati event or an event, a / character, and a semicolon- 
separated list of actions. 

The event is a logical expression consisting of a number of 
comparisons. Comparisons are linked with logical OR opera- 
tions indicated by the I character and logical AND operations 
indicated by the & character The logical NOT operator, indi- 
cated by the - character, can be used to invert an expres- 
sion or comparison. Order of execution can be indicated by 
the use of parentheses. Each comparison consists of either 
just a variable or a variable, a comparah n symbol, and a 
constant value in double quotation marks. The comparators 
can be equal = f greater titan >, less than <, not equal -=. less 
than or equal to <-. ( >r greater than or equal to >=. 

Each action consists of the name of a variable, an equals 
sign = f and the value to be assigned to thai variable in double 
quotation marks. 

This gives .« bexl block of the form: 

mc_timed_0LJl I 
( mc_jarn_sense & 
mc_prcker_state= l 'mc_prcker_op0n" > / 

mc_X_motion_di re ctian="m c_X_br ake" ; 

mc_a ction=* m c_ jammed" 

This should be read as follows: tf mcJimed_out is true, or both 
mcjam„sense is true and mc_picker_state is mc picker open, then 

set mc_X_motion_direction to the constant value mc_X_brake and 
set mc_actian to the constant value mc Jammed and transition 
to the next stale 

This text is parsed using a parser written using the yacc and 
lex tools provided with the HP-UX* operating system, thi^- 
generates a reverse Polish form for the logical expression 
along with t hi 1 values required for the ad i< >n> 

Generating the State Table 

The major issue with the state table design was tormpleiii' ni 
the lull syntax supplied by the I earn work/RT stale transition 
diagrams in as compact a form as possible. Performance 
was ROt an issue The maximum response time required of 
the firmware was of the order of 3 ins. This was easily 
itrluevuhle with the designs chosen. 



hi'L ember li&4 ll'-wl^r Packard Journal 



ZH 



)Copr. 1949-1998 Hewlett-Packard Co. 



To produce a machine readable form of the transition 
information, each part is taken in Jam. 

To reference variables, the 118 processor uses 1 6-bit address- 
ing, This can be Truncated to 10 bits to limit the address space 
to the 1024 bytes of RAM available on the processor. Since 
there are over 3000 references to less than 50 variables, an 
index table is far more efficient. In the transition information, 
a six-bit index value is stored. This is used lo look up the 
address uf the* variable in an array of point em. 

Since every variable in the logical expression is associated 
with a comparator, it would be useful to store the informa- 
tion indicating the comparator in the spare two bits with tin 
variable index. Unfortunately, iherearesix < mnparators, 
which would require at least three bits to store, However, 
the comparators form pairs of Inverses, Bgual is the oppo- 
site of not equal greater than is the opposite of less than or 
equal to and less than is the opposite of greater than or 
equal to. As such, the logical NOT operation is used so thai 
only the three basic comparators have lo be used in the 
state table, allowing the comparator to fit in the two spare 
bits of the variable index. Since most comparisons are 
equalities, this saves a great deal of space while preserving 
the simple table format with no items crossing byte bound- 
aries. All comparisons arc with 8-bit values. These are 
sin red in the hyie after the variable index and operator 

The logical operators are stored in single-byte values. Tliis is 
wasteful since only a couple of bits are really required for 
these However, it maintains Ihe simplicity of the generator 
and interpret ei' by avoiding Ihe necessity of table items 
crossing \ >v i . - I ■ i > u nclaries. 

The expression is stored in the table in reverse Polish format 
with the comparisons as values. The expression is terminals d 
v\ ir!t a zero byte to indicate where calculation should stop. 

Each action consists of the six-bit index for the variable 
stored in one byte and the single-byte value to be assigned 
Stored in the next byte The list Of actions is terniiiuih'd by a 
zero value to indicate the end of the list 

While most of ihe anions involve assignments of a single 
byte, the setting up of timeouts requires thai a 16-bit value 
for the timeout in milliseconds be set. This variable is con- 
sidered a special case by the state machine generator and 
tw T o assignments are generated. This maintains the readabil- 
ity of the stale machine diagram without adding complexity 
tq i he stale machine table to handle lo-bii \ allies. 

The final part of the transition information is the next state. 
This is given as a single-byte value. 

The state table entries for the transition text example given 
rather are; 

I mc_timed_GLJtJndex I 128), l r /* = */ 

t mc jam_sense_index 1 128 ), \ t /*== 7 

I mc_picker_state_index i 128 ), mc_picker_Dpen r /* == 7 

\J*AUDV 

X /• OR 7 

0, 

mc_X_motion_directJon_inc)ex, mc_X_br3ke r 

mc_actfon_index. mc Jammed, 

0, 

0. 



The transition data for each state is generated in turn. At the 
end of the transitions out of a given stale, a single byte of 
value 255 is inserted to indicate the end of the transitions 
associated with that state. 

To access the transitions associated with a given state, a 
table of pointers is used. The pointer indexed by a given 
state number points to the. first I rausition from that stale. 

A single byte of data is nsed to hold the number of the 
current state. This is the same value as appears on the 
Teamwork/RT diagram. 

Finally, a structure is generated that holds a pointer 10 the 
stale pointer table, a pointer to the index variable, a pointer 
to ihe State variable, and a code to be used for logging. 

The complete data structures for the state table are show n 
in Fig. 2. 

State Table Interpreter 

To execute the state table an interpreter pout toe is used. This 
reads the state table and carries out the actions required. 

The interpreter routine is passed a pointer to the header 
structure for the state machine to be > M^imd, It uses the 
pointer to the state variable to gel the current slate. It uses 
i iiis as an index into the state pointer table in gel a pointer 

10 the transitions for the current state. It then scans the 
transition information. 

The first thing in the transition informal ion must be an ex- 
pression, terminated by a zero byte. The interpreter routine 
checks each byte in turn to see if it is a comparison, an 
operation, or the terminating zero. 

If either or both of the top bits are sel I Ikml it is a rompari- 
sonand the next byte is the value lo be compared The but- 
torn six hits of the byte are used as an index into the index 
table to get the pointer to the variable to be checked. This is 
I hen used to get Ihe variables value. The first two bits are 
used to determine whether the comparison should be for 
equality, greater than, or less ihan. The next byte is read, the 
comparison is executed, and the result is placed on a slack. 
The current byte is then incremented past both bytes of the 
comparison. 

If neither of the top two bits is set but the value is not zero, 
then the byte indicates a logical operator If the operator is 
AND or OR. then the top two values are removed from the 
stack, the operation is carried out on them, and the result is 
pushed back on the slack, If the Operator IS NOT. then the top 
wilne is pulled of ft he stack, inverted, and pushed back on. 
The current byte is then incremented past die operator 

This is repeated until a aero byte is found as the current 
byte. Then the top value is pulled off the stack to indicate 
whether the expression evaluated to TRUE or not. 

If the expression is TRUE, the actions are read in turn as byte 
pairs until a zero byte is fi mud as the first byte* For each 
byte pah; the value in the second byte is assigned to the vari- 
able pointed lo by the pointer in the index table indicated by 

1 1 ii index in the first byte. When die terminating zero hvte is 
found, the next byte is assigned to the state variable a! id the 
interpreter routine exits, having completed a transition. 
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Stale Pointer Table 



State Variable 



State Table 
Header Structure 



Variable Pointer 



Variable 1 Painter 



Variable 2 Pointer 



Variable 3 Pointer 



Variable n P&inte* 



Index Table 



State D Pointer 



State 1 Pointer 



State 2 Pointer 



State n Pointer 



State Pointer 
Table 



State Variable 



State Transition 



State Transition 1 



Stale Transition n 



State 1 Transition 



State 1 Transition 1 



State 1 Transition n 



State 2 Transit inn 



Slate 2 Transition 1 



State 2 Transition n 









State n Transition 



State it Transition 1 



State n Transition n 



Transition 
Information Table 



Fig. 2. State table dais structures. 



if the expression evaluates to FALSE, the actions are skipped 
i n rr until a /en j index is found. The nexl byte is skipped as 
well, since this is the next state value. The subsei|iiciii byte 
is i !i. i k< il to see if there arc any n inn » transitions n 
cess. If this byte is tun 2S6, then another transition follows 
ami it is processed in the same manner. If i his byte is 25$j 
then all the transitions have been processed and none have 
conditions ihai an- true. The Interpreter routine exits with- 
out carrying out any actions or altering the state variable 

Initialization and Exception Conditions 

The state variahie must be iuiiiah/ed al startup lor the initial 
state of the sy^em Rather than pro vide a mechanism for 
the initialization routines to know the initial state, an addi- 
tional state is added To ihe slale machine. Any transitions 
on the diagram that conned off-page are viewed as connect- 
ing to this additional state. Since the initial transition that 
identifies the initial state is the only one thai can come from 
Off-page, I his allows the initial state In be s<r merely by set- 
ting it lo zero. As soofi as the state machine is executed, it 
will transition into ihe initial state on the diagram. 

When an exception occurs, it is useful to be able in restart 
I In - state machine to initialize those areas of the mechanism 
Under its eontroL Bailer tliati connect all the transitions dial 
handle exception conditions to ihe initial state, these are 
allowed tonm off-page, in the Team wot k/RT notation, this 
nii'-'i •• ih.it Hi" state machine has exited and thai it should be 
restarted from the initial state cai Its ftesSt invocation- Since 
these off-page connectors conned m the additional state ( > 



i f .is lias exactly the desired effect. The exception transition 
ran then he made to restart the state machine without the 
clutter of unnecessary connections on the diagram 

Debugging and Trace Logging 

To be able to debug problems with a real-time control system, 
ii is importaill to be able to get trace information back front 
iti» unit after a failure to determine what the system wm 
doing at thn in ie oj failure With a system thai is largely im- 
plemented as slate tables, it is possible lo follow die flow of 
actions in terms of the stale changes involved. As such, the 
state table interpreter was designed with a tracing function 
built in. 

Whenever a state change occurs, the state table iuterpn jtet 
logs tlir current nine as a L6fbii rolling clock counting in 
millisi < "ink dir s bit log value in ihe stain table header 
Structure thai identifies which state machine is being exe- 
cuted, at id the 8-bit value of the new state. The resultant 
32-bit value is stored in an internal rolling buHVi and Is also 
transmitted on one of the IIS processor's built-in serial lines 

To decode this trace information, host-based interpreter 
programs are used. These decode ihe information in the 
trace log to identify exactly w hit It state table and state within 
lite table arc involved. These ate ihen pruned out using the 
names on the Teamwork RT slate transition diagrams. This 
enables die changes in state to be followed on the diagrams 
merely by following Ihe names gh en. The time < aeh state 
was entered is listed alongside the name of the state U\ facil- 
itate the interpretation of the mechanical factors diat may 
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have eaused the state change. The use of milliseconds 
throughout, both for timeouts and for trace lodging, allows 
engineers debugging failure rn wmk in reat -world values 
rather than units that are solely dependent on the software 
design. 

During product test, the serial output from the micropro- 
cessor is monitored and the data is interpreted in real time. 
This allows both real-time debugging of failures and the 
gathering of a complete history of a lest. In the held. the 



rolling buffer is returned from tbe autochanger via its S( SJ 
interface. This only allows ;i receul hisiory to be relumed, 
but does not require additional hardware to monitor the 
serial pfcft 

HP-UX as based on and is compatible with Novell's UNIX'"*' operating system It also complies 
with X/Opens* XPG4, POSIX 1QG3.1, 1003.2 ffPS 151-1. and SVfp? interlace specific 

UNIX is a rec ■ irk in the United Steles and other countries, licensed BKCk&lvfity 

through X/QpenComprj; /ilfriteJ 

X/Opsn is a trademark of X/Q|v- . .rnfed m the UK and atftef tountnes. 
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Using State Machines as a Design 
and Coding Tool 

The wide acceptance of real-time extensions to structured analysis 
techniques have led to the use of state machine descriptions for the 
specification of systems in which state or sequence is a vital part 
However, the techniques for implementing these specifications h 
remained poorly understood and haphazard, leading to implementations 
that are difficult to verify against the specification. This paper examines 
different approaches to the use of state machines and explores their 
advantages and disadvantages. 

by Mark J. Sinims 



In die theory of state machines, two types of state machine 
model are defined: the Mealy Model and the Moore model 
In the Mealy model. Outputs are associated with transit U>as, 
When a transition happens, die output is generated. The for- 
mat of this type < ff state t&m nplementcd in GaU I 
Teamwork software is shown in Fig. 1. In the Moore model 
outputs are associated with stales. When a stale is entered. 
theoutpul is generated. The ioi mat of this type of state 
machine as implemented in Teamwork is shown in Fitf, 2. 

Traditionally, the Mealy stair maehine model has been used 
for software systems. Teamwork versions prior to 4.0 did 
not support tin Moore stale machine model. This is because 
software state-based systems typically only take action in 
response to an event. An output is set on die transition ,il 
though it may remain set indefinitely This is sometimes not 



the optimum way of approaching a state-based model, but 
tends to reflect the way software engineers think. 

As a result, this paper will concentrate on the Mealy model 
and references to State r Machines may be taken to assume 
this model unless there is a specific reference to the contrary. 
All of the Concepts can he applied to Moore-model state 
machines because any Moore state machine can be imple- 
ment <-d as aJMealj sraie machine, although the converse is 
not true. 

When die original a inc^lsctfsttttetuied analysis were pro- 
posed h\ Tom DeMarco, 1 ao concepts of state or sequence 

were used. This led to difficulty in modeling a large rlasv , rf 
problems, m< luding real time control systems that aretegefy 
based around state and sequence and have little data flow 
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Fig. 2. \i"i>t-r si ftie machine. 



content. As a result, two proposals were made for extensions 
to the structured analysis notation thai would enable this 
type of problem to be modeled. 

The first proposal came from Paul Ward and Steve MeHor,- 
whu introduced a concept of signals lo the structured anah 
sis notation. Signals differ from data Hows in that they amy 
timing information but no data. There are two types ni sig- 
nals: events and prompts. Events are generated by state 
machines and by data transformations in response to 
ehanges in the em ironm* nl and cause state transitions 
within the state machine. Prompts are general ed by state 
machines to control data transformations. Ward and Mellor 



proposed three types of control that could be exercised on 
data transformations: enable, disable, ant I trigger. Teamworlc/ 
SIM adds the kill prompt. The format of a Ward-Mellor state 
machine is shown in Fig. 3. 

The second proposal came from Derek Ilatley and Imliaz 
Pirhhai, ' who use the concept of a control now. Control 
Hows have the same properties as data flows, but are used 
for control purposes. They carry data and are continuously 
valid, Tin 1 only way to pass timing information is to change 
the value of a control flow in response lo an external event. 
Logical expressions involving input control flow values are 
used to determine when transitions of a state machine take 




Engine. Running,'' 
Trigger "ReseLCruise' 



Resume/ 
Enable "Acceleratejn.Desired, Speed 





Start lncreasing_Speed/ 
Enable "Accelerate'' 



Accelerating 



Activate/ 

Trigger " G et_ Speed " 



■a 



Start lncreasing_Speed/ 
Enable " Accelerate" 



Resume/ 
Enable "Acce(erate_ta_Desired_Speed" 



Step. . I n creasing . Spe ed/ 

Disable 'Accelerate_tc_Desired .Speed" 

Enable 'Maintain Speed_ReacherJ" 



Start. Increasing Speed/ 
Enable Accelerate" 



St op_ Increasing Speed/ 

Disable "Accelerate" 

Enable ' Maimain_Speed_Reached r ' 




Activate/ 
Trigger 'Get. Speed" 



Brake Engaged/ 
Disable 
'Maintain, 
Speed. Reached" 



Brake_Engaged 



Fig. 3. \Yum-M«r-Ilt>r state m;»< I 
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Fig. 1 HmI"> ■■[ ■ Uine 

place. Assignments are used in a state machine to control 
1 fir \ alues of output control flows. The format of a Hat lev ■ 
Pit hliai state machine is shown in Fig, 1 

Ward and Mellors signals can only lie used in a Mealy stale 
machine since they have an instantaneous quality and it 
makes little sense to have an instantaneous signal associ- 
ated wilh a slate. This could he Interpreted as ihe signal 

being sent whenever the state is enured, but 1 1 lis Es really 
associating it w ith aU the transitions intg the statii 

Hatley and Pirbhai's control flows can he used w 1M1 either 
slate machine model. If the selling of control flows is ass. .--i 
ated with transiiions in a Menh State machine. 1 1 iev are as- 
sumed to be set until actively reset on ;moi her transition. If 
the setting of control flows is associated with states in a 
Moore state machine, then the control How is deemed to be 
undefined if the state machine is In a state that does not 
active]}? otttpul thai control How Fins Leads bo a clearer defi- 
nition of whai is happening with a Mealy state machine and 
therefore a tendency to use this model 

Design Criteria 

When using stale machines as a design tool rather than an 

analysis tool the method of implementing the state machine 
must he considered to give the design a rigid definition. In 

1 1: i j titular, the means of passing flu external inputs to the 
state machine and the way the state machine interfaces to the 
procedural flow of the rest of the code must be ui-ll defined 

Wand and Mellor rect unmend thai the analysis be partitioned 
into tasks according to the number of state machines III i he 
system. In addition io the state machine, the data trans- 
formations that it prompts and the event recognizers ihai 
supply ii wiih events mav be m the same task. This leads to 
a very simple interface io the msi of the code. The state ma- 
chine ts the i op-level module of the task. It calls an event 
recognizer io get an event from the outside world. 1 
recognizer returns an evenl to the state machine if one is 
available or returns a code indicating no evenl if no event is 



available. The state machine then executes the transition 
by flagging data transformations as enabled, disabled, or 
triggered and changing to the next state. It executes an\ 
enabled or triggered data transformations by calling ihe 
relevant procedures Kmalh, ii -ets the stale of triggered 
data transformations to disabled before calling the event 
recognizer again 

This implementation approach has a leu drawbacks Kirs!, if 
there are a large number of state machines, then the number 
of tasks can become very large. For systems that have to be 
implemented on hardware with limited power, this can be 

VG13 wasteful To get mound this problem, a system b\ which 

multiple siate machines can be implemented in a single iask 
is required Tiii^ can be done by rnaMrtg the state machine 
ret u?it control to the calling procedure after each loop. This 
allows multiple state ttidchtoes to be called in sequence, 

This also allows other data I ransfon nation modules to he 
called in the same sequence, imitating the parallel nature of 
the analysis. 

Secondly, m systems thai are 1 apable of susj lending tasks, 
the Ward Mi lint approach is very wasteful of processor 
time. In 'his type of system, the event passing mechanism 
should be built into the operating system in such a manner 
that Tasks can block until an event is generated This works 
v. 'II if (riggers are the only prompts required, If data iraus- 

formations must be enabled and disabled, the operating sys* 
tern must be used to do this, However; thismighi produce 
excessive operating system overhead 

The most efficient implementations based on 1 his type of 

n require 1 hat 011K l riggers be used, hut multiple si, n> 
machines can be executed in the same task With these re- 
sinetions the Ward MeUoi design approach can be highly 

I Mi- i"iit for targe and medium-si/ed systems. A real time 

operating system handles the scheduling of the tasks and 
can block a task waiting for a semaphore to he set. The 

semaphore can !><■ set 1 tthej (33 anothei tash oi i-> an Inlet 

I I ip •( ser\ ]> t murine res| Minding to an external event, A 
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counting semaphore can be used to allow mtih iple events to 
activate a single task. Alternatively, a message queue mecha- 
nism can bo used to implement a similar lecrmioiio. Jl events 
are passed between state machines in the same task then 
this can be implemented by flags Uiat are checked by Un- 
even! recognizer before suspending. 

The top-level module in each task is responsible for calling 
the event recognizer routine. This blocks iniiil (fie task's 
semaphore is set, it then determines what event occurred 
and returns I he corresponding event code to the lop-level 
module. The appropriate state machine is called based on 
the event code and passed the code as a parameter. The 
state machine determines i\w data transformation modules 
to be triggered and executes them in turn. It assigns the new 
state and returns. The event recognizer is then called again. 

Ilatley and Pirbhai offer far less guidance than Ward and 
MeUor on how to com erf structured analysis state machines 
into designs. However, the meaning of the state machine 
appeals more obvious at First sight. leading to a fairly 
i A >vious design. 

Since the control flows are simple data values, these are 
easily implemented as static variables. The state machine 
needs only to read the variables, evaluate the logical expres- 
sions on the transitions in sequence until one is found to be 
I rue. oxeeuto the assignments on that transition and assign 
tlie new state. This continues with the transitions from r ho 
new state. 

This approach has I wo problems. First, the on lor in which 
the transitions are processed is arbitrary. This means that 
the actions performed by the implementation are not nei.es- 
sarily uniquely determined by the state machine description. 
This is, however, a problem with Hie underlying analysis 
method. Il is the responsibility of the analyst to ensure 
either that no two Iransitions become active simultaneously 
or that the system will operate within specification even if 
they do. 

Second and more serious, the state machine offers no 
obvious way of interacting with the environment other than 
through the static variables. Tins means that the State ma- 
rl tine would ideally run in its own task interfacing with the 
rest of the system via the variables representing the control 
flows. This is a highly inefficient implementation. This can 
be improved by implementing the state machine in such a 
manner that it returns control to the module that called it 
after each cycle. This allows several state machine modules 
and associated data transformation modules to fee placed in 
the same task. This improves efficiency some what, but still 
usi j s processing time when nothing is being done. 

Because of die inefficiency of this soil of implementation it 
can only be used where there is sufficient processor time to 
spare. However, it does have advantages when there is no 
operating system or where the operating system only offers 
basic functional ity. Since rhe state machine operates on 
global variables, some simple data transformations can be 
incorporate d into the state machines. This can produce a 
design that is veiy easy to learn and to follow and that can 
be implemented very easily. 

It is sometimes advantageous to add some of the features 
of control-flo w-based state machines to signal-based state 



machines. TIiIn involves adding states that control Hie How 
of the state machine based on the value of variables There 
should always be at least one exit transition active when- 
ever such a state is entered. These states are not true states 
since the state machine never waits in the state. Instead 
they are merely decision points that affect the future flow 
through the state machine. Under certain circumstances, 
litis can greatly simplify the state machine. 

Implementation Techniques 

There are two major approaches to implementing state 
machines in software. The first is to generate inline code 
that executes the state machine logic directly, This is the 
faster solution, hut uses a large amount of code space. This 
approach is typically used on large systems where there is a 
lot of memory and on systems where response time is very 
important. 

The second approach is to generate a table that encodes the 
state machine logic in a compact manner that is then inter- 
preted by a Separate state machine interpreter. This pet tfraees 
very compact code that is suitable for Systems where code 
space is low and response time is not critical. 

Both signal -driven and control-flow-driven state machines 
can be implemented either as inline code or as tables. Vari- 
ous different coding schemes can be used depending on the 
complexity of the syntax used for the state machine. In sys- 
tems where the state machine module never returns, the 
program counter can be used to determine the state. More 
usually, however, a static state variable is used to maintain 
the state between calls of the state machine module. 

For a Hatley-Firbhai type state machine, this leads to an 
implementation of the form shown in Fig. 5. The state ma- 
chine is implemented as a single C function. A static variable 
within the function holds rhe state. This variable is initial- 
ized to the initial state ol the stale machine when the task is 
started. The function is structured as a switch statement in 
winch each case limb is the processing for a given state. The 



void state_ machine! void ) 
I 
static state - Enffine_Qff; 
switch ( state ){ 
ease Eughe_Dff; 

if ( Engine. Running —True }{ 
Action = Resel_Cruise; 
slate = Idle; 
J 

break; 
case Idle: 

if 1 Command = Resume \{ 

Action = Accelerate to Desired Speed; 
state = resuming; 
} else if [ Command = Star|Jncreasiftg_Sneed \{ 
Action = Accelerate; 
stale = accele rating; 
} else if i Command = Activate } { 
Action = Gel_Speed; 
state = Initialize; 
1 

break; 
easel Slowing )■ 



break: 
1 



Fig. 5. Code for Hatley-Pirbhai stare machine. 
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crjefine number ot enabled functions 3 
•define Accelerate, to _Desired_Speed_INDEX 
tdefiite Ace el e rare _ INDEX 1 
sdefme Mamta?n_ Speed .Reached INDEX 2 

void \ 'function array H \{ numbtr_of_er«ililed_functions 1 : 

{ accelerate to desired speed 

ateeierate, 

ma imam speed reached 
h 

iitt enabled afrav; numijeF_aLenatited functions ] 
= f FALSE FALSE. FALSE I 

void stste_ machine! int event I 
i 



static int state = Engme.Oft 
int i 

switch I state i { 
case Engine, Off: 

if I event — Engine Running I | 
Reset Cruiseii, 
stale = Idle 
I 

break, 
case Idle: 

if ( event = Resume ){ 
enabled array! 

Accelerale_to_Desfred_Speed INDEX J 
TRUE, 
state s Accelerating; 
) else if ( event = Start Increasing Speed S [ 
enabled arr a vf Accelerate INDEX ] = TRUE; 
states Accelerating, 
I else if I event — Activate \{ 
Get SpeedO; 
state - Initialize; 
} 

break; 
case Slowing: 



break; 

1 

for j i = i < number of enabled . functions; i++ | { 

if I enabled arrav{ i )M 
I unci ion arrayl i ](|; 

I 
I 



the array. At the end of the function, the array of flags is 
searched and the corresponding functions are called via the 
pointers in the second army. 

This design makes a few assumptions about the calling envi- 
ronment. First, [he event recognizer functionality is not in 
the state machine itself The event recognizer is executed in 
the calling environment and the ever passed as a 

parameter to the function. Secondly, the calling environment 
must not block because this would prevent the enabled 
modules from being executed. Since the enabled modules 
are called as functions from the state machine, the si 
machine function must be executed at least as often as the 
enabled modules need m be called. 

Since the content of these state macliines is fairly simple 
and well-defined, machine code is a somewhat inefficient 
way of storing it. As a result, in systems where code space is 
at a premium, it maybe advantageous to Implement the >u- 
script inn of the state machine as a table that i eied 

by a separate routine. The following paragraphs describe 
one possible way of doing this for a Hatley-Pirbhai si 
machine. 

The state machine n insists of an array of pointers and a 
state variable. The slate variable is used as an index into the 
array to get the address of an array of structures containing 
a pointer and a value. Each transition consists of a single 
condition structure followed by a series of action structures 
and then a structure with a null pointer and the destination 
state Dedicating the end of the transition, The end of the 
transition; iven state is indicated by another structure 

with a null pointer. This is depicted in Fig. 7. 

To execute this state machine, an interpreter functiOTi i> 
given the stale variable and the list of pointers. Using the 
state variable as an index In to the table, it uses the corre- 
sponding j Joint ei to find I he fust si i in tine corresponding to 



Fig. 6. Wanl-V .It*. 

cast* limb corresponding to the currently active state \$ 
CUted when the function is called. This tests the exit condi- 
tions Tor the state in a series of if statements, If nne of these 
is qualified, then the actions are carried out in the statements 
airaHiod to the if statement and the m w state is assigned- 
The function is then exited mallow othei processing to be 
carried out in the sum- lask. 

For a Ward-Mellor type state machine, this approach leads 
to an implementation of the form given in Fig. 6. TVo an.: . g 
are used, The First holds pointers to all the functions that are 
enabled and disabled. The second holds a flag indicating 
whether 1 1 1 ■ < function is cunvnily enabled or disabled, The 
function that implements the state machine has many simi- 
larities to that for the Hat ley Tirhhai stale machine. It is 
structured as a Switch statement with a case limb for each 
state. Kach rase litnb t unsists r A if statements thai deter 

mine if ibe corresponding actions should be executed- ] fie 

coui Ml iuus use<l are far more restrictive Mian in the Hat ley- 
Pi i-hhai ease. The\ check whether the event code passed In 
the function as a parameter is the value corresponding to 
the required event. The actions are either triggers, which 
Mmpk * all r he I unci ion that corresponds to the required 
ad i' m. or enables and disables which set and clear flags in 
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Fitf. 7. State tables for a table-drivei sta& machin* 
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a transition from the eurrcnl State, It then checks to see if 
the condition is true by comparing the variable pointed u » I »v 
the pointer wii.h r lie value stored in the structure. Ii they are 
different, the table is scanned until a structure with a null 
pointer is found indicating the end of that transition. The 
procedure is (hen repeated until cither a true condition is 
found or a condition with a null pointer is found. If a condi- 
tion with a null pointer is found, all the Conditions have been 
t est ed and ihe inierpreier function re t urns to its calling 
environment . 

If a condition is found to be true, the interpreter function 
scans i he subsequent structures and assigns each value in 
flte Structure to the variable indicated by the corresponding 
pointer. It continues lo do this until a structure with a null 
pointer is encountered, indicating the end of the transition. 
It assigns the value in this structure 10 the state variable 
to cause a change of state. It then returns to its calling 

environment 

A similar approach can be used for Ward-Mel lor state ma- 
chines. Event codes and pointers to functions to be enabled 
or disabled ate encoded in the tables. This requires a slightly 
more flexible table format, but the principles are the same. 

Automatic Generation 

Once a rigorous mapping has been defined between Ihe 
state machine design and the code to be produced from it, it 
is theoretically possible to design tools that can translate 
state machine descriptions directly lo the source code for 
the final software, Willi the extensive use of graphical state 
machine editors for analysis, this gives the potential for a 
graphical form of source code that is easy to follow and easy 
to modify, removing some of the major p rob terns of software 
maintenance. 

Analysis tools are not designed with direct code generation 
in mind. As a result, the mappings from state machine de- 
scription to code must be defined by the engineers on ihe 
project using the tools. This allows a lot of flexibility for 
experienced engineers to produce mappings that are highly 
timed Ht i he application concerned. It does mean that there 
is a requirement for anyone wishing to learn about the code 
to determine what the mapping is and why it was chosen. 
Once this is understood, the functionality of t lie code can be 
followed from the state machine diagrams. 

For a structured analysis tool to be able to fulfill this role, it 
must have a number of features. The following are some of 
the most important: 

• 'Die tool must support the state machine features required 
by the implementers. This includes Mealy and Moore state 
machines, types of conditions that cause transitions, types 
of actions that can be placed on transitions or in states, size 
mid complexity of diagrams, and so on, 

• It must be possible to integrate the tool into the configura- 
tion management system. Sime \\n- state machine diagrams 
are now source code, it is vital that they be treated with a 
high degree of care and attention, 

• The tool must be able to access the diagrams. If the data is 

■d in any sort of database system, the appropriate access 
routines must be supplied. 

• The tool must keep diagrams in a documented formal thai 
does not change between revisions. Continually modifying 



code generation programs to track the formal oftiic 
diagrams is unacceptable, 

Once these features have been established, code generation 
becomes a simple task of defining the mapping between the 
state machines and the code and then designing the transla- 
tor program and any interpreter routines for table-driven 
state machines. The rest of the eode can ihen be designed 
fiporo the remainder of the structured analysis with the state 
machine implementation in mind. 

There have been a number of dedicated code generator pro- 
grams on the market for some lime, many of which use state 
machines as part or all of their input tools. These systems 
come with rigorously defined semantics for their diagrams 
$ i i hat users of the system can rapidly understand designs 
with which t hey a re unfamiliar. These programs also come 
with a defined mapping of the diagrams to code. 

The biggest problem with this sort of system is that the fea- 
tures of the state machines and the mapping to code supplied 
by the vendor may not be ideat for the implemeiiUil ion I hai 
is required for a given problem, Few systems Currently avail- 
able offer any ways of tuning the unplemouialinn for a given 
set of design criteria. This is one ol the major features lo 
look for in such a system. 

A hybrid approach is possible in which a code generator tool 
is used, but a custom front end is included to lime the result- 
ing code from the generator. This might be done cither by 
Mealing the tool in the same way as a generic structured 
analysis lool and accessing the diagrams and generating 
code directly from them or by postprocessing the resultant 
code to optimize it for the given situation. 

The hybrid approach is probably harder lhan designing a 
generator for a generic struct ured analysis tool Inn Ihe re- 
sults could be belter. The added rigor of code generators 
means that it is easier to use standardized semantics for the 
system. The semantics are more likely to be complete than 
those of a structured analysis loot 

Summary 

The use tn] ness of state macliines for specifying eontn >1 
applications has been well-proven. Their use in design and 
implementation is also showing a great deal of promise. It 
has shown major advantages in the following areas: 

• Rapid code implementation because ot The very close 
mapping of analysis, design, and code 

• Ease of maintenance because of the availability of casy- 
lo-read code in the form of state machine diagrams 

■ Compact implementation of a large proportion of Ihe 
fund u nudity of a problem because of the use of table-based 
state macliines. 

These advantages make the investment in tools for this 
technique well worth the effort and expense involved. 
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An Event-Based, Retargetable 
Debugger 

Remote and event-based debugging capability, a sophisticated graphical 
user interface, and adaptability to different languages and target 
platforms are some of the features provided in this debugger 

by Aran K. Iyengar, Thaddeus S, Grzesik, Valerie J. Ho-Gibson, TVaey A. Hoover, and John R. Vasta 



Software devetopecs rely heavily on debuggers for both 
fixing bugs and analyzing programs. The information ob- 
tained by a debugger can be used to add new features and 
Improve performance. Event-based debugging 3 is a powerful 
method for examining program behavior, In event-based 
debugging, the user instructs the debuggei to respond to 
events thai occur during prograin execution. The proper 
selection of events allows programs to be debugged at a 
higher level than would otherwise be possible, 

11 lis article describes the Hi ted Debugging Envin in 

meni (IIP DDE)," IIF' [»J)K is distributed because it is capable 
of debugging programs executing on remote hosts, HP DDE 
bus been ported and retargeted to several platforms and can 
be used to debug programs written in C, C++. F( >RTRAN, 
Pascal, and various assembly languages. The platforms that 
IIP DDE can rim on include the HP-UX* operating system. 
I >nin;iiiL( )S bSK. Domain/OS Prism, the SPARC implementa- 
tion of Solaris, and the PA-Risr implementation of the OSF/1 
Operating system, MP I > I > K has a sophisticated graphical 
user interface that provides ih<- user with point -and cliefi 
access fco commands and program stale. Finally, HP DDE 
has mam features thai support event-based debugging and 
debugging optimized code, 

The modular architecture of HP DDE enhances its portability 
and has been a eritieal component in its success, HP DDE 

dstsofa main debugger that communicates «dth several 
modules called managers, The main debugger contains sup- 
port for generalized debugger functions, and the managers 
contain dependencies on specific kmgu ■■' r code for- 

mats, target platforms, and user interna w 

User-Visible Features 

Event -Based Debugging in HP DDE 
Almost ml debuggers support a traditional debugging para- 
digm in which the user inserts breakpoints before critical 
points in the program and examines the state of the program 
alter breakpoints are hit to find program errors. The disad- 
vantage of this paradigm is that the user has to know where 
to insert breakpoints within the program The user may also 
have to examine the State of the program at a number of 

breakpoints before "blaming the desired infonnaiion. 



In event-based debugging, the debugger does not return 
control to the use* until an event defined by the user occurs. 
By choosing an appropriate event, the user can avoid stop- 
ping the program at points that are not critical. Event-based 
i lebugging allows the user to identify what is going on in a 
program without spending large amounts of time inserting 
breakpoints at crucial points, 

Event-based debugging is achieved by monitoring the exe- 
cuting i in ilj am at an interval or granularity level specified 
b\ the user, Whenever the debugger determines that a de- 
sired event has occurred, the debugger rettfi ns ( oni p A to 
the user, a lower level of granularity, corresponding to fre- 
qaent monitoring, allows the user to determine more accu- 
rately the location where a particular event occurs. How- 
ever, a low granularity level can cause execution time to 
increase substantially. HP DDE provides several intervals 
for monitoring program execution, including every' machine 
instruction! every source statement, and entry to or exit 
from each procedure, Monitoring can be restricted to spe- 
cific procedures within a program Typically, a user would 
use p roredu re-en iry-ar al-ex ii -level granularity to narrow an 
event to a specific procedure. Alter the faulty procedure is 
located, the user can use souneslutement level or machine- 
instruct ion-level granularity mthin the procedure to deier- 
mine the exacl location of an even I. 

HP DDK contains many features for event-baaed del nigging 
including conditional breakpoints^ execution traces, data 
watchpoints, and event intercepts, i ondiiionai breakpoints 
alinu the uset to halt i-xi'« uiioii at a given point in a pro- 
gram only if a set of conditions are met Execution 1 r ; i ' 

end program exeeuta ai at ml ervnls specified by the 
user Data waiehpornts allow the usei h> monitor a variable 
or memory range (program execution is suspended when a 
value corresponding io a watched variable or memory range 
changes). Event intercepts allow the user to regain control 
«>r the program when events sm-ii as program exceptions, 

shared library loading and unloading thread creation ami 
termination, and signals hum the operating system occur. 

The IIP Dl »E command language allows the user to declare 
variables for use in a debugging session and contains loops, 

conditional^ and assignment statements to allow a wider 

range of event specification. 
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Examples 

Suppose thai the user desires to suspend execution every 
tune a variable x becomes zero. This can be accomplished 
with I he following IIP DDE command: t 

dde> watchpoint x-da [if [x != 0) —then (go)J 

The behavior when no monitoring interval is specified in the 
watchpoint command (as in this example) is to monitor the 
expression after every source statement. 

As ai -.ample, suppose (he user wishes to break upon 

entry to function foa only ii argument x is nonnegative. This 
can be accomplished using a conditional breakpoint: 

dde> breakpomt foo -do [if (x < Q\ -then (go)| 

It is possible for the user to examine data structures while a 
program is suspended. The following IIP DDE commands 
will prinl all positive elements of a 20-elcment array A: 

dde> declare intdde_var 

dde> setdde_var=0 

dde> while dde_vsr < 20 -loop [if Afdde_var] > 0-then \ 

(print Afdde var]|;\ 

set dde_var = dd e_var 4- 1 ] 

The declare command allocates space for new variables that, 
can be used in debugging sessions, and the backslash (\j indi- 
cates that an IIP DDE command continues on the next line. 

The following commands will suspend execution whenever 
the sum of the 20 elements of A is greater than 100: 

dde> declare inti 
dde> declare int sum 
dde> watchpoint A -do \ 

[set i=0; set sum = D; \ 

while i < 20 -loop \ 
(set sum = sum 4 A[iJ; set i = i + 1j; \ 

if sum <= 100 -then (goH 

Sequences of commands such as these can be stored in a file 
and used as input m HP DDE. In addition, macro expansion 
allows a user to define a single command that is automati- 
cally expanded by the command interpreter into multiple 
commands. 

As a final example, the following commands will execute a 
program and print the number of times a multithreaded 
application switches between different threads: 

dde> declare intts_count 
dde> set ts_coun.t - Q 

dde> intercept thread switch -do [setts_eount = t5_courit + l;goj 

dde> go; print Isocount 

The User Interface 

Several user interfaces have been designed for HP DDE. The 
most sophisticated is a graphical user interface based on the 
X Window System and OSF/Motif. 9 Ii features multiple win- 
dows, context-sensitive pop-Up menus, and online help. The 
user can customize menus, command buttons, and key bind- 
ings, A typical HP DDE debugging session with four win- 
dows is illustrated in Fig, 1. The graphical user interface can 
manipulate up to six different types of windows: 
• Target program window. This is du window from which IIP 
DDE is invoked. All data to mid from the program being 

t HP DDE debugg-ec commands can be entered in the command entry ■ ne wen n ihe transcript 
display whhIow described in (he next sectmi.. 



debugged is directed to this window The main parameter to 
the debugger is the name of the program to be debugged 

• Transcript display window. This is the debugger's main 
window It has fell* components. The command entry line 
compound I a* the bottom of the window is for keyboard 
entry of debugger commands. All debugger commands can 
be entered from the keyboard iit litis area. Above the com- 
mand entry line is the transcripi area, which displays Input 
to the debugger (including commands accessed from Hie 
mouse) and debugger output. The buttons along the left side 
of this window provide quick access to common debugger 
mmmands. For example, the user can single-slep the pro- 
gram (execute a single source statement ) by clicking on the 
button labeled Step. These buttons can be reconfigured by 

I he user to represent oilier commands. The pulldown menus 
across the top of the transcript display window allow access 
to all debugger commands via the mouse. 

• Sunnv r<nir display window. This window displays the 
source code For the program being debugged 

• Assembly display window. This window displays ilu j dis- 
assembled machine instructions tor the program being 
debugged. 

• TYaeeback display window. This window displays the current 
c \y n a i ii i c cal 1 chai n of t he target p rogram . 

• Variable display window. This window displays the values of 
variables or memory ranges for winch watchpoints have 
been set. When a watched value changes, IIP DDE suspends 
execution, notifies the user of the change in value, and 
updates the variable display window with the new value. 

Context-sensitive pop-up menus allow the user to access 
common debugger commands with the mouse. Menus ap- 
pear when the mouse is clicked. The menu that appears de- 
pends on the position of the mouse within a particular win- 
ckrw at the time the mouse is clicked. For example, clicking 
on the mouse with the cursor positioned in Ihe source code 
region brings up the menu displayed in Fig. 2. The cursor in 
Fig. 2 was positioned at the opening bracket of the expres- 
sion fistli] at the time the mouse was clicked. The menu was 
thus seeded with the expression list[i]. If the cursor had been 
positioned over list, the menu would have been seeded wilh 
list instead of list [i]. The mouse can be positioned lo print 
complex expressions in source programs without requiring 
the user to type in the expressions. 

For even quicker access, double-clicking causes IIP DDF lo 
execute the first menu item instead of displaying the menu. 
The default pop-up menus contain actions that are commonly 
performed by users. However, pop-up menus can be easily 
reconfigured by users lo contain unions lhai are common to 
a particular application. 

Debugging Optimized Code 

Af a high level Optimization can be described as modifying 
instructions and memory references to improve program 
performance. Multiple source statements may map to Ihe 
same machine instruction. In some cases source statements 
may not correspond to any machine instruct ions. Variables 
may be moved from memory into a register or from one 
register to another ro eliminate costly memory referem . s 
Unless a debugger has some way of knowing how source, 
statements and machine instructions have been rearranged 
and where a variable is located, it can be very difficult to 
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Distributed Debugging Environment - Session IB? 70 
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int sum (list, low, :. . 

lr.t iist[], low, high; 
! 

int i, s - 0; 

for i = i:-v; i <- high; i++) 

s += listfij; 
return ( s ) ; 



void print_averag* (list, low, high) 
int listlJj low, high; 
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int Eum (list, low, hi'ih) 
int list[], low, 
E 

-, s - 0; 
for (1 - low; 1 <- blah; 

a += listji]; 
I at urn (s) ; 



void p.rij ige Clist, low, high] 

mt 1 1st 1 3 # low,, high; 

Int total, num e] age; 

total « sum Hist, low, high); 
rji.im_e laments - hi ah - low; /* not* 



DDE User Menu 



print lisi | i] 

watch list[il 

describe list[ij 

prim haxllat[f] 

print fderef one*!) Ifet[L] 

print (chase ptrs) Ltstfi] 

break list [i] 

- Cancel - 
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Itioning th^ mouse i u 
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and clicking 0^1 a tnou le i ■« n i • -i - 
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mix; 



Workstation / X Term mo I 
(Local Host) 



wlule [x < 101 
f(x+H 



Range 1: 
xmR3 



Range 2: 
xinSP 60 



return x; 



Kig. 3. K\;in:.i^ oi r,ni;i<- [oeafcioilk VnruitiJe x has r v.. ■ i |qi ; it ions: 
1 1 ■-'.!■-■! it 3 iii lu-inge 1 and 60 bytes below ; in i, r _■ ■ _ 

debug aii Optimized application al flu- source level. Program- 
mers often must resort to debugging at the assembly level io 
gain ail accurate understanding of program execution. 

HP] H >E rt ml aii is some support lor debugging optimized code 
at the source level, However, fhe.se features are only usable 
if the compile! provides adequate debugging information. 

On HP Apollo's Domain/OS, (he compilers produce range 
locations for variables (see Fig. 3). The range location record 
contains a program coimter range and a location for the vari- 
able that is correct for the range. A variable may also have a 
delauli location so that its range locations need not cover 
the em ire instruction ranges in which the variable is active. 
Additional information is provided containing the many-to- 
many mapping between source statements and machine 
instructions. Currently on the HIM X operating system only 
the mapping between source lines and machine instructions 
is provided. 

Given the appropriate information from a compiler, HP DDE 
can indicate the source lines associated with a particular 
machine instruction and the machine instructions for a par 
I ieular source line. This type of information can help the 
user determine the flow of control in an optimized program. 
When the user wants to see the value of a variable. HP DDE 
determines the correct symbol location based on the current 
program counter and the range local ion information stored 
for that symbol. 

See "Compiler Optimizations and Debugging" on page 37 
for a short discussion about the importance of debugging 
optimized code. 

Remote Debugging 

IIP DDE is capable of debugging programs running on a 
remote system. This can be accomplished by running most 
of HP DDE on a remote system and redirecting input and 
output to a local host, or by naming most of HP DDK on the 
local system and the application and a small part of HP DDE 
on the remote system. The latter approach is currently onh 
available on local hosts running Domain/OS. 

To run HP DDE remotely on a typical UNIX R workstation, 
the user can simply run HP DDE on the remote system and 
refined the OSF/Motif user interface to the X display on the 
local host (see Fig. 4a). The X Window System's portability 
allows HP DDEs user interface to be displayed on any sys- 
tem that supports the X protocol 

Alternatively, ihe user can execute most of HP DDE on a 
local host tunning Domain/OS while the application | i • 
gram executes on a remote system (Fig, 41 u A small part of 
HP DDE must also execute on the remote system to handle 
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Pig. 4, Itojpesslbie remote H£DD£ sessions (a) M->>' ofUFDBJE 
and the f ;p[']HTiiion being do hugger 1 \m- ran <hi a n-n ■■.'■■ v, -.-■■m and 
the HP DDE user inu-rfcicr- is run from an X lei'miani. Qb) Most of HP 

1 >1 iK \$ r;i :i [qq$ hi.*] ;.inl u portion "I'HP DDE ;md the appli- 

'■;itH4i 8t*e run Gfl B i'> -r. n ■ • s.\>l- in 

commuiiH -at ion between the remote and local systems. This 
is a useful method for debugging programs if the remote 
system cannot run HP DDE on its own, as is often ihe case 
for embedded systems or prototype systems, 

The implementation of HP DDK's remote debugging capability 
is described later in this article. 

Comparisons to Other Debuggers 
I>b\ ] and grjb ' are two commonly used workstation debug- 
gers and Dhxtool/' which is a window- and mouse-based 
debugger built on top of dbx, is also well known and has a 
graphical user interface similar to diat of HP DDE, None of 
these debuggers has the range of features for supporting 
event-based debugging provided by IIP DDE. The dbx and 
dbxtoo) command languages do not allow the user to de- 
clare new variables during debugging sessions and d< » not 
contain loops or conditional statements. In addition, HP 
DDE has a larger number of options for specifying monitor 
points at different levels of granularity than dbx and 
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dbxtool. The gdb command language does not contain loops 
or conditio j i 

ral event -based debuggers have bt*en developed as re- 
search prototypes. Unlike IIP DDE, they are not available as 
commercial - I tolek 1 is a sequential event-based 

debugger which bs i of gdb, Dalek allows high- 

level events to bedefiiM .ver-level 

Is superior io HP I rvidingthe ability 

. h-level events. However, HP DDE is probaJ 

r to use because our goal has be 
with powerful e\ ent-based debugging features which can be 
used with little effort A number of event-based debuggers 
have been developed for parallel and distributed systems 

have looked at die problem of debugging 
optimized code. Hennessy 1 ' 1 presents algorithms for deter- 
mining the value of variables in an optimized program. When 
the debugger is stopped at a breakpoint and the user tries U * 
print a variable x k the debugger should output the value of x 
that is consistent wftfi the order of execution <■! ^laiements 
in ihe imoptimized program. Since the Optimizer ran reorder 
3tatements, ihe value stored in the memory location for x 
may not be the value the user expects to see. Hennessy pn »- 
vides an approach for calculating the value of x when the 
\ all h slorei l in the appropriate memory location is not th> 
yalue the user expects to sec \ debugger called DOL' 1J uses 
an approach lhat is similar to that of Hennessy and has bet- 
ter capabilities than HI' DDE I'm' determining the value of 
variables. Convex 12 has developed a production quality de- 
bugger with elaborate features for debugging optimized code, 
TTie i on vex debugger uses visual highlighting of source and 
.nhk displays to indicate ihe flow of control in an opti- 
mized program. HP 1)1 )K does nui have any of ihe visual 
highlighting Ceanires present in the Conves debugger, The 
SELF debugging system 1 " shields the debugger from eoin 
piler Optimizations by dynamically deupiimi/,ing code. SELF 
uses dynamo compilation which means that instead olYoin- 

i >i I ing entire programs prior to execution, code is generated 
Incrementally ;it run time and kepi in a cache Dynamic de- 
opttaizatiori is generally nor feasible foi languages ih.n do 
not use dynamic compilation, In addition, ihi.s approach is 
insufficient tur bugs that occur in the optimized version ol a 
program but not in the mmptimized version. 

Architecture 

As a class of tools, debuggers perform a wide range of 
operations from very lovv-ievef target -specific operations to 
middle-level, language-specific operations to bigh-leve) user 
interface operations. Because of the nature of these opera- 
tions a debugger can i>e difficult eg port and retarget 

HP DDE has been designed fan a modular fashion with the 
goal oi isolating otyeel code dependent, language dependent, 
target dependent tuni user toterfece dependent functions 
from generic debugging functions The MP DDE architecuire 
consists of a main debugger and several managers, which 
ii < -iiii^orized according h» languav objed code, 

and u^(m interface type (see Rig, 6), 

The Mia;,-, debater Is designed io provide .1- many generic 
debuggei operations as ii can without compromising \\» 
generality <>f HP DDE. Examples of these operations Include 
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^.v^tl compiling techniques 
fcject code can be mate to run faster 
ormat ions known as optimizations 
code transformations are known as 



In an unopttmiffid pogra- 
a source sis* 

one-to-one correspondence no longer exists in many cases, and i 
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n the order implied by the source code Tfiis complicates de- 
g Programmers must often resort to debugging assembly code to figure out 

trow an gram is behaving 

In general, users should debug the unoptimezed version of a program before . 
the optimizer However, there are a number reasons why me ability to debug 
ized code is desirable 

* A program may run correctly when compiled without apttmiaation and 
compiled with optimization This can happen even if the optimizer is working 
correctly For example, reordering statements may result in arithmetic overflow or 
underflow. An uninitialized variable or an out-of-bounds memory reference might 
cause a prublem in the op ,n but not in the unopti mired version 

* The time or space requirements 0? an unoptimi/ed program might be too hig id 
a I tow adequate tt 

1 Production code is often optimized A customer may submit a bug report with a 
core file produced from an optimized program. It would be desirable to have the 
. to anaryte foe cob f3e. 

■ Optimizing compilers can be written more easily with good tools for debugging 
optimized code. 

1 The compiler may not have the ability to generate unoptimized code. 

1 Tf\e programmer may have mistakenly supplied explicit assertions, directives, or 
options that causetJ ti n j compiler to generate incorrect code. 

i Optimizing compilers may have bugs. 



symbol table and program monitor management The manag- 
ers perform operations that ate specific to a givm machine, 
language, compiler, or user Interface, Kadi manager has art 
interface specification that defines roe operations a particular 
manager should provide. A manager is formally defined as 
am piece of software Ghat correctly implements the functions 
defined in fche uiteiface specification. 

The main debugger also has a set of functions catted callback 
functions that managers can invoke to obtain Information 
from the main debugger- As ihe main debugger satisfies a 
User command, it can call on the various managers to pi 
Tumi operations provided in a particular manager, Aim! v 
a manager is satisfying a request torn the main debugger il 
can request information from fch< bugger through a 

callback function, 

Managers do not communicate with one anothe] because MP 
DDE is structured so that it should not he necessary. This 
strict partitioning allows a developer to port and retarget a 
manager or develop a new manager as 1 m ■• ■'■ ssary without 
modifying other managers or the main debugger. 

In 1 J if main debugger and managers, platform-specific system 
rails are avoided except ta the lowest level parts of the man- 
agers. However^ systemr^ecific calls are generall) needed, 

so we have implemented a set of general-purpose utilities, 
part of which can be customized for the target platform 
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They are generally independent of the functions of a debug- 
ger and can be used by any application. In all of the system- 
specific calls we try to be compliant with the latest version 
Of POSIX 

These general -purpose utilities include a list utility, a hash 
table utility, a memory allocation utility, and a string handling 
utility. The memory allocation utility provides a generic inter- 
face to .system memory management functions such as malfoc 
and free. It allows a caller to allocate memory directly from 
the heap or to allocate a cluster of storage, which is man- 
aged separately from the rest of the heap and from which 
smaller pieces of memory can be allocated later. 

Because of the partitioned implementation scheme, HP DDE 
can support a wide variety of target machines, languages, 
object code formats, and user interfaces simply by imple- 
menting new managers. Although implementing a new man- 
agrr is not a trivial task, supporting a new architecture or 
object code formal is generally straightforward. 

The Main Debugger 

The main debugger constitutes the largest and most complex 
part of HP DDE. It contains the implementation of generic 
debugger operations that control and maintain information 
about a debugging session. The design of HP DDE is such 
that most debugger functionality resides in the main debug- 
ger so that managers can be small and easy to implement, 
The main debugger supports a wide variety of platforms and 
I *U h k-st nurtured lai m i W ges 1 rttf 1 1 takes lew assumptions al >out 
their specific properties. When the main debugger need:- 
target, language, or object code dependent information it 
calls a manager io supply it 



Just as HP DDE is divided into the main debugger and vari- 
ous managers, die mahi debugger is further sub d hi dec! into 
several distinct packages, each of which implements a well- 
defined subset of the operations provided by the main de- 
bugger. Although the main debugger is not written in C~+, it 
has been implemented using an object-oriented methodology, 
and a package is similar to a class. Each package defines a 
function interface to the data it controls, such that one pack- 
age can only refer to die data in another through the function 
interface. Parts of these package interfaces are exported as 
callback functions for use by the various managers. 

Most of the services provided by the main debugger fall into 
one o f th e fo 1 1 o win g c ategori es : syt n h o I ta b 1 e 1 1 ta 1 1 a ge mem, 
command dispatch and processing, program monitor man- 
agement, abstract syntax tree construction and expression 
evaluation, slack management, location identifier parsing, 
target program execuiion management, user interface dis- 
play management, and short-term and long-term storage 
management. 

Symbol Table. HI* DDEs symbol table is managed by the 
main debugger and initialized by the object rode manager 
through callback functions. The symbol table isolates the 
main debugger from differences hi debugging information 
emitted by different compilers and is versatile enough to 
represent programs in all languages that HP DDE supports. 

Other parts of the main debugger and other managers can 
call the symbol table package to obtain information from the 
symbol table. Although IIP !>l 'K is dependent on the cor- 
rect ti ess of the symbol table, as is any debugger. IIP DDE 
i -; not assume that the symbol table is complete. If a 
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piece of information is m.t in the symbol table, an error 
does not occur. This behavii >r requires the ral k to 

see if the symbol table package returns the expet ted piece 
of inforntatioi"L 

A Short Primer on Debugger Internals" at righl 
more aJ ring a t Jelnigging session. 

Abstract Syntax Trees and Expression Evaluation. To remain as 
language independent as possible, the main debugger imple- 
mei ige Lan- 

ill this package to generate intermediate 
[anguagel trees representing language * ms. The 

intermediate language is powerful enough to represent 
most expression constructs for ail languages that HP DDE 
supports. 

nine a language manager has constructed a language inde- 
pendent intermediate language tree for a language expression 
specified by the user, the tree is returned to the main debug- 
ger for processing by the expression evaluator package. The 
evaliiator calls other packages and managers lo determine 
the value and type of the expression- 

During expression evaluation, some language-specific infor- 
mation may be needed For example, arrays are laid out in 
column-major forma i in some languages and in row-major 

i in others, < 'titer language dependent abstractions 
include the case-sensitivity of the language, w hether a string 
is mill terminated, various at tributes of arrays and pointers, 
and type-checking rules. Like the set of intermediate lan- 
guage constructs 1 IP DDE supports, this group of language 
abstractions is meant to be representative. For example, the 
main debugger knows the variety of ways arrays are treated 
in different block-structured languages and how to neat 
each one correctly. However, the main debugger does not 
know the language of the expression, but only the value of 
the particular attribute, 

Short-Term and Long-Term Memory Management. B© attse HP 
1 1] H: is implemented in a Strictly partitioned manner, man- 
agement of heap storage can be difficult < )ne package or 
manager can allocate a piece of data, but has no way of 
know ing w hen it can be freed, To simplify this problem, the 
main debugger uses die general-purpose memory allocation 
utility mentioned earlier to implement a higher-lrvH m 
pad 

At the Stat itiuu the mam debugger allocates a 

cluster of Storage, wliieh it uses as temporary space. Callers 
in The higher4eveJ storage ■•■ cac request a pie< e ol 

the temporary cluster for storage that is needed only briefly 
rather than throughout a debugging session. A package or 
manager thai requests this temporary space does not need 
responsible lot freeing it because the entire cluster fa 
Freed and reallocated at the end of each command execution 
i \- I' 

Pol example, the abstract syntax tree package allocates 

intermediate language nodes in temporary storage because 

the types and values of expressions are determined within 
one command cycle, and the Information Is no longer needed 

< met' it haa hern displayed to the user i >u Hm - 1 rther kind. 



r Am riRm- <ised as an intermedin' 

original (high-level) source code and ihe (low'lerell target Ian , i 



A Short Primer on Debugger Internals 

When using a debugger, the user typ be able to stop the program at 

■je of a program s. tne 

flow of control by stepping Through the source lines in a function, or 
e the program execution stack to rjetemvne howexecutmn ended tip at a 
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A debugger uses the rnf&rmation in the symbol table to translate a symbolic loca- 

tal address Once a debugger has a virtual 
address for a program location, it can set a program monitor (such a 

watchpoint) at that location Once the virtual address for a program 
symbol is known, a debugger can find its value and display the value according to 
the symbol's type 

fa determine the type and value of a language expression speeded by the user, 

which may range from a simple variable reference to a complex expression, a 
debugger needs some way to determine if the expression is correct. One way to 

■ctjonality is witn a parser that translates the expression into 
some sort of abstract syntax or intermediate language tree marje up of operator 
nodes and operand leaves This tree is then evaluated to determine the type and 
I /alue of the expression 

The contents of the symbol table are important to a debugger, but it aiso needs 
access to the address space of the target program On many UNIX systems, de- 
buggers control the target program with the ptracefl system call With ptraced a 
debugger can read from and write to the program's address space, execute the 
program for one or many instructions, and send a signal to the program For exam- 
ple, nnce a debugger has translated a program location into a virtual address, it 
uses ptree&i) to write a special instruction into the instruction stream of the target 
p r og r am E m ie speci a I i nstructi on cau Bes the target pr ng ra m t o stop 

and the debugger to regain control of the target program 



symbol table and breakpoint information is allocated in long- 
term storage because it is needed throughout a debugging 

session. 

Target Managers 

Target managers are responsible toi providing debugger 
functionality specific to tin* hardware, operating system, 
and run-time libra the® components tend to be 

platform-specifiCj n is critical t<» isolate the dependencies on 
these components from the main debugger 

The two major goals In isolating platform-specific dependen- 
cies within targei rflMagersan tn makoil easier lo pun IIP 
DDE m ci new platform and to facilitate remote debugging 

nti heteri fgeneous sy st en t s , 

The target manager's primary responsibility is to control the 
program being debugged and repon the state of tin- program 
to the inaiii debugger. A carefully defined interface has been 
created to hide the details ufhmv a program is controlled and 
inspected These details often vary widely between hard? 
platforms, operating systems, and run-time libraries, 

HP UnEsiij-jiurt^drhuggiugdrtlinads based tin the I'OSJX 

threads model. Each thread lias a uniiuie registei jet, stack, 
Mini rail chain. Every thread in a program can be examined 
by the main debugger. The target manager hides the details 

Ml i threads implementation. I'nt example, cmrenHv mi the 

him \ operating system^ thread control is implemented 
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using a run-time library. However, on the Solaris operating 
system, thread control is embedded in the kernel. 

The target manager uses an event-driven model to communi- 
cate with the main debugger. The main del nigger directs the 
target manager to resume the urogram and report buck 
events when execution is halted. Program events are trig- 
gered by several circumstances, including breakpoints, data 
wan -hpoints. traces* faults such as UNIX signals, shared 
library loads and unloads, program forks and execs, thread 
crealion, termination, and context switching, and C++ 
exception catches and throws. 

For every event, the current program counter and stack 
pointer are reported to the main debugger. The target man- 
ager alsf i constructs the dynamic call chain. Every event is 
associated with a specific thread. The thread that triggered 
the event is selected as the primary thread, but the main 
debugger can also examine the program counter, stack 
pointer, and dynamic call chain of all other threads in the 
program. For events such as shared library loads, the name 
and address spaces of the shared library are returned. For 
events causer I by a fault such as a UNIX signal the type of 
fault (e.g.. signal niirnhci ■') is returned, 

When the target program is halted, the target manager pro- 
vides a variety of services to the main debugger; The current 
state of the program can be uueried or modified. Machine 
registers and memory can be altered, and program functions 
can be called. Thread scheduling order and stale can be 
changed. Program Forks and execs can be lot I owed to debug 
the new process. For program forks, both the parent and the 
child can be debugged simultaneously. A separate debugger 
is spawned lo debug the child program 

The target manager also handles issues related to run-1 hue 
libraries. Run-time libraries tend to vary with hart I ware plat- 
forms and operating systems. An example of this is the C+- 
run-time library. The implementations of certain language 
features, such as exception handling, arc embedded in the 
C++ run-time library. HP DDE's target manager interfaces 
with this library and handles events such as throws and catches. 
For example, to stop on a C++ throw, the target manager sets 
a hidden breakpoint on the run-time routine that handles 
throws. .After the hidden breakpoint is triggered, the call 
chain can be followed to find die user routine thai issued 
the throw. 

Remote Debugging Capabilities 

As- mentioned earlier. IIP DDE supports remote debugging in 
two different ways. The fust way is to urn most of IIP DDE 
on a remote host and redirect input and output to a local 
host, and the second way is to run most of HP DDE on the 
local host and the rest of IIP DDE and the application being 
debugged on the remole system. This section describes the 
second way. 

HP DDEs remote debugging capabilities are handled by the 
target manager. HP DDE is started on a local host system 
and instructed by the user to debug an application executing 
on a remote target system. A portion of the target manager, 
the target debug kernel, also executes on the remote system 
\ see Fig, 6). The main pail of the target manager runs on the 
host and communicates with the target debug kernel. The 
target debug kernel interfaces with the hardware, operating 



Workstation 
(Local Hast} 






1 



Remote 
System 



' Operating 
System 

Run-Time 
Libraries 



LAN 



HP DDE 

Main Debugger 


Hr 


Mar J 3 '*" 
u M«inager 
Managers _" . 
s Main 


1 ^| | 


IRS 



Target Debug 
Kernel 



Application 

Being 
Debugged 



Fig. 6. Remote debugging $i ■:->. ion $h living the 'listribunon of the 
target nuimiger sofUVtiR'. 

system, and run-time libraries of the remote system. Com- 
munication between the host and remote system is handled 
entirely by the interface between the target debug kernel 
and the rest of the target manager. Other DDE managers and 
the main debugger are not aware of the interface between 
the host and remote system, or even the fact that the target 
program is executing on a remote system. 

The method for communicating between the local host and 
remote system depends on the protocols common to both 
systems. One possibility is to communicate via remote pro- 
cedure calls. This is the protocol used for remote systems 
running the HP Apollo Domain/t >S. Km bedded systems that 
do not support remote procedure calls might use a simpler 
protocol. 

Remote debugging is most useful when the largei system 
docs not have all the functionality or resources to run HP 
I )l >[•:. For example, when porting HP DDE to HP Apollo's 
PRISM system, remote debugging was needed during early 
development before the operating system and run-tune sys- 
tem were fully bun -lional. Remote debugging can also be 
used to lessen the load on I he remote system, Since all bm a 
small piece of HP DDE is running on the local host system, 
the local host supplies resources such as memory and CPU 
to rim HP DDE. 

Object Code Managers 

Object code managers are responsible for converting 
symbolic debug information generated by compilers into HP 
DDEs internal symbol table format. The object code manager 
functionality was separated from the target manager to take 
advantage of common symbol table formats across target 
platforms. An object code manager that recognizes a partic- 
ular symbol table format can be reused on any platform that 
uses the same symbol table format. 

The object code manager creates HP DDEs internal symbol 
table in several stages. When a program is fh"st loaded, the 
object code manager creates the primitive data types that 



40 December I9&4 Hewlett- Rfteksfd Journal 



)Copr. 1949-1998 Hewlett-Packard Co. 



mig! ured by a program (e.g., integral and floating- 

point types in various sizes}* The object code manager also 
lies a mapping from those primitive types to language- 
specific type names (such as char or mi for 

primitive data types are created, the ><1e 

manager enters information about the program being de- 
bugged into the symbol table. Program infonnaiior 
hierarclij- The object code manager creates a 

subtree in the symbol table for each executable file in a pro- 
grant Each level of a tree is known as a block ■< ks 

represent the lexical structure of programs. Blocks contain 
symbol and line number informal ion tor the lexical scopes 
they represent. The root bK vil- 

lains symbols global to the executable file ir represents, is 
know n as an image block. Fig. 7 shows an example of a 
symbol table block. 

s> ihIm »] lable elements are created for each g] or 

variable at program load time. However, symbols local (■« 
i he child blocks of an image block do not have to be created 
immediately. HI 1 DDE can incrementally initialize local sym- 
bols when They are needed. If a block is never referenced 
the local symbols of the block may never have to be entered 
into fchie B5 mpol table. HP DDE s startup time and space re- 
quirements aiv reduced by minimizing the amoinii Of initial 
information in the symbol table. 

After the program is loaded, the object code manager may 
subsequently be invoked if the program dynamically Ir m Is i 
new executable shared library. 

HP DDE makes very few assumptions aboul Hie level of 
Support proviiled by an ubjeri code mana^ei Symbol tabic 
information can be sparse. An object mile manager ran pro- 
vide limned support for debugging programs thai were not 
Compiled in debug mode by doing such things as using the 
linker symbol (able information, hi this case, the level of 
symbolic debug support is reduced 

Language Managers 

Language managers are responsible for the language-specific 
aspects of a debugging session \ separate language manager 
exists for each language supported bj HP DDK, including C, 
( + + . Fortran, Pascal, and various assembly languages. Mul- 
tiple language managers can be loaded simultaneously, 

HP Dl »K uses language managers when evnluahng and print- 
ing ex pressions. up DDE has a language mode thai deter- 
mines bow expressions are evaluated. The default language 
moiie is the language corresponding to the current poim «>f 
program execution. However, the programmer can override 
the default language mode. Kach language manager is re- 
sponsible for parsing expressions according to the syntax 
of the language, [f the expression islega^ an intermediate 
guage toe representing the expression is created, The 
main debugger evaluates the Intermediate language tree in a 
bottom-up fashion and invokes the language manager during 
this evaluation. The language manager b called to type ch© k 
each nonleaf node in the intermediate language tree before 
the node is evaluated H'a lype-checkkig error occurs, the 
language manager can either hall the evaluation process m 

mSG\ i type rumvrsiun nodes IlltO the intennedinte language 

nee in make the operation legal, 



int sum Hist low, high* 
in! listU, tow. high 
{ 
in! i. s = 0; 
lor (i = low; i «■ high. i++i 

s+^iistftt 
return (si: 
1 

= block image 1 a outtaverageMum = 

name; sum 

stsrt_line_nr 12 

end line nr 19 

source Jite average c iMon Jul 25 11 10:53 1994) 

stmt list 

— statement V, imageia out Average \surrrl 5 
line_nr 15 

start oHsec 16 
end .offset 19 

— statemem \YimagtfaDUtr«verage\3iim\12 — 
line nr!2 

stan offset: 
end offset IS 

— statement Wi mag e( a. airt?\av era geSsurnM 6 — 
line_nr: Ifi 

start offset: 20 
end , offset: 39 

— siatemeni \Vimage(e.oittr«verage^timM7 — 
line_nr:17 

start .offset: 40 
end_offset: 91 

— si a tenteni W image ( a.o u t}\a ve ra g e\s u m\1 8 

line_nr: 18 

stati_effset 92 
end offset: 99 

— statement WJmagefa.outfaverag e\sum\19 — 
line ii r 19 

start_ offset: 100 
enOffset 107 

sym list: 

— symbol Wima ge(a out leaver age^umMist — 
name list 

datatype: pointer 
attributes: [ pa ram by vat j 

— symbol VV imaged a. out ^averageVsumMow — 
name; low 

datatype: int 

attributes: I pit ram by val ] 

— symbol \Vimagela.0utShavBragB\3urfl\high - — 
name: high 

datatype: int 

attributes f par am by val 1 

— symbol VVimage(aoutNverageNsum\i — 
name: i 

datatype int 

attributes: f stack variable ] 

— symbol\Vimage|aouii\awerage\sum\s — 
name: s 

datatype: int 

attributes: f stack variable ] 

Fig. 7. >nnir i.j in- r i.. ii;,,;.... table block 

for tto ■ sum, which Is part oi i 



A language manager performs a number nfjuixilinry tuiu- 
i inns ms well, including formatting data for output ;mtl defin- 
ing the value of several attributes thai the main debugger 
uses to conform to the behavior of the language currentl> in 
effe< i Examples include whether tdentiflers are < a^< sexist 
tive. whether an array of characters is equivalenl to it string, 
m whether a pointer can bo indexed as if it were an array. A 
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language manager mI.su del ermines huu text Is Selected from 
1 1 P D I ) E s use r interface displays. The usei ran 

define a point-ond-click operation to select arguments lor 
debugger commands. When a user clicks a mouse hull on on 
text displayed sorne^ here in the user interface, file current 
language inanagci determines the text the user is referring 
to from tlif position of the mouse cuipprfaese Pig. ?}. 

User Interface Managers 

Ti ic main r#e ef a user interlace manager is to eoiieei user 
input, convert user input into debugger commands, send 
commands to the main debugger, and display output from 
the main debugger. As described earlier, five different out- 
put areas me defined in HP DDE: the source code display, 
assembly code display, stack traceback display, watched 
variable display, and transcript display (see Fig. 1 ). The user 
interface specification allows considerable freedom in the 
way these displays arc 1 implemented. A user interface can 
ignore output for every display except tbe transcript display, 
which records the interactions between the user and HP 
DDE. Commands exist to enable and disable the other dis- 
plays and to redirect output intended for other displays to 
iln- transcript display, 

A user interface is dynamically loaded by tbe main debugger 
at startup time. Although several user interfaces exist, there 
is no way to switch user interfaces after one has been spe- 
cified ai startup time. 

The most sophisticated user interface provided by HP DDE 
is tbe GUI described earlier. A more primitive line mode 
user interface also exists for systems that do not support X 
Windows and OSF/Motif. 

Implementation Experiences 

Our experiences with the IIP DDE architecture have been 
positive, and its design concept has been validated by the 
number ol limes HP DDK has been ported. The interface 
specifications allow developers to write new managers with- 
out wonying about other parts of HP DDE. However, we do 
pay a price for such an extreme level of generality and ab- 
straction. For instance, our source line count is currently 
hn\ ering around 260,000 lines, which is high compared with 
tbe dhx and gdh debuggers, Machine resources consumed 
by HP DDE can be quite substantial, particularly when de- 
bugging large programs. In addition, performance can be 
suboptinial because several function calls must be made 
nearly every time a piece of information is needed from 
another part of the debugger. 

Although the original designers of the HP DDE architecture 
did an exceptional job designing and implementing the de- 
bugger abstractions, some assumptions did creep in. For 
instance^ it is fairly straightforward Co support a procedural, 
block-structured language. However, we recently imple- 
mented extensive G+* support and certain aspects of the 
implementation were rather difficult because of various 
features of the language such as inheritance and dynamic 
type identification and the dependence on the run-time sys- 
tem. To preserve modularity, the interface specifications do 
not allow one manager to make a direct call to a function in 
another manager However, the implementation would have 



been easier if the language manager had the ability bo aiake 
direct calls to target and object eode manager functions. 

One of the problems in developing HP I >DE lias been tbe 
partitioning of debugger functionality into a main debugger 
and different managers. The goal has been In put as much 
functionality as possible into tin* main debugger while keep- 
ing MP DDE as general as possible. While most of the origi- 
nal manager interface specifications are still valid, modifier a- 
i ini is have been necessary For example, the target manager 
interlace specification was modified extensively to provide 
multithreaded debugging support. Also, the language man- 
ager interface specified joii was modified to enable more 
extensive C++ debugging support 

In addition, IIP DDK was originally implemented on HP 
Apollo's Domain/OS, which provided a great deal of support 
for different aspects of debugging, including a procedural 
interlace Jo I lie shared library loader and an enhanced ptracet) 
(process trace \ facility that allowed the debugger to follow 
the child of a forked process. Paris of the manager and call- 
back interfaces were designed with this additional Operating 
system support in mind, ( onseiiueiiik. target -related opera 
tions and event processing are often more complicated on 
I -NIX implementations with less sophisticated debugging 
support. 

One deficiency that HP DDE has in common wtlh many oilier 
tie I niggers is the performance of watchpoints and conditional 
breakpoints, In HP DDE, watchpoints are implemented by 
setting hidden breakpoints at the granularity requested by 
tbe user and monitoring data at these breakpoints. Each 
time execution stops at a hidden breakpoint, the current 
value of the data must be compared against the old value- If 
the monitoring interval is short, a great deal of time is spent 
slopping at breakpoint sand performing comparisons. 

Conditional breakpoints are implemented in a similar fash- 
ion. The expression specified by the user is stored with the 
breakpoint information. Each time execution reaches the 
conditional breakpoint, tbe expression is parsed and evalu- 
ated. Depending on the complexity of tin ■ expression and 
I tie frequency with which the breakpoint is triggered, this 
can be lime-consuming. 

Conclusion 

HP DDE is a multilingual debugger that has been ported To 
several different platforms. Event-based debugging features 
altnw I lie user 1o debug programs at a higher level than 
Would otherwise be possible. HP DDE atop has the ability to 
debug applications running on remoie systems and to debug 
optimized code. The sophisticated GIT provides many fea- 
tures that aid usability, including multiple windows, context- 
sensitive pop -up menus, arid online help. 

HP DDE's modular architecture consists of a main debugger 
and several managers. The manager's encapsulate dependen- 
cies on target platforms, object code formats, languages, and 
user interfaces. Manager interface specifications indicate 
the sei vices required from new managers To support new 
target platforms, object code formats, languages, and user 
interfaces. 
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Wavelet Analysis: 
Theory and Applications 

Wavelet analysis has attracted attention for its ability to analyze rapidly 
changing transient signals. Any application using the Fourier transform 
can be formulated using wavelets to provide more accurately localized 
temporal and frequency information. This paper gives an overview of 
wavelet analysis and describes a software toolbox created by HP 
Laboratories Japan to aid in the development of wavelet applications, 

by Daniel T.L. Lee and Akio Yaniamoto 



Wavelet analysis (also called wavelet theory, or just wave- 
lets J has attracted much attention recently in signal process- 
ing, II has heen successfully applied in ninny applications 
such as trans i en t signal analysis, image analysis, conunu- 
imations systems, and other signal processing applications* 
If is nol a new theory in ihe sense that many of the ideas and 
techniques involved in wavelets (subband coding, quadra- 
ture mirror filters, etc.) were developed independently in 
various signal processing applications and have been known 
for some time. What is new is the development of recent 
results on the mathematical foundations of wavelets that 
provide a unified framework tor the subject. 

Within this framework a common link is established be- 
tween the many diversified problems Thai are of interest to 
different fields, including electrical engineering fsigna] pro- 
cessing, dam compression), mathematical analysis (harmonic 
analysis, operator theory), and physics (fractals, quantum 
field theory). Wavelet theory has become an active area of 
research in these fields. There are opportunities for farther 
development of both the mathematical underst andjng of 
wavelets and a wide range of applications in science and 
engineering. 

Like Fourier analysis, wavelet analysis deals with expansion 
of functions in temis of a set of basis functions. Unlike 
Fourier analysis, wavelet analysis expands functions not in 
terms Of trigonometric polynomials hul in lenns of traivlpfs, 
which are generated in the form of translations and dilations 
of a fixed function called the mother wavelet The wavelets 
obtained in this way have special scaling properties. They 
are localized in time ami frequency, permitting a closer con- 
nection between the function being represented and I heir 
coeffic ients. Greater numerical stability in reconstruction 
and manipulation is ensured. 

The objective of wavelet analysis is to define these powerful 
wavelet basis functions and find efficient methods for their 
computation; II can be shown that every application using the 
fast Fourier transform (FFT) can be formulated using wave- 
lets to provide more Localized temporal (or spatial) and fre- 
quency information. Tims, instead of a frequency spectrum, 



fer example, uiii' gets a wavelet spectrum, hi signal process- 
ing, wavelets art 1 very useful for processing nonstationary 
signals. 

Wavelets have created much excitement in the ntal hematics 
cimuiumiiy (perhaps more so than in engineering) because 
ihe mathematical development has followed a veiy interest- 
ing path. The recent developments can lie viewed as resuh 
ing some of the difficulties inherent in Fourier analysis. For 
example, a typical question is how to relate the Fourier co- 
efficients to the global or local behavior of a function. The 
development of wavelet analysis can be considered an oul- 
grovvrh of the Littlewood-Paley iheory 1 (first published in 
1931), which sought a new approach to answer some of 
these difficulties. Again, it is the unifying framework made 
possible by recent results in wavelet theory related to prob- 
lems of harmonic analysis {also to similar problems in oper- 
ator theory called the CalderomZygmund theory 1 ) that has 
generated much of the excitement, 

En electrical engineering, there have been independent devel- 
opments in the analysis of nonstationary signals, specifically 
in the form of the short-term Fourier Iransform, a variation 
of which called the Gabor transform was first published in 
1946.- A major advance in w r avelet theory was the discovery 
of smooth mother wavelets whose set of discrete translations 
and dilations forms an orthonormaJ basis for L-f Rj, where R 
is the real numbers and L- is the set of all fund ions, f, ihat 
have bounded energy, that is, functions for which 



I 



Ifft^dt < 



This is a main difference from the Gabor transform. In the 
Gabor case, no orthonormaJ lias is can be generated from 
smooth wavelets. Tims the unifying framework brought 
about a better understanding and a new approach that over- 
comes the difficulties hi the short-term Fourier transform 
methods. 

In the next section w T e give an overview of The main features 
of wavelet analysis and then aim to a software toolbox that 
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HP Laboratories Japan has developed 10 help in the develop- 
ment of wavelet applications. 

For ail excellent tutorial introduction to the subject, see 
and Veltcrli- and the r< therein | (I lists 106 

references), Daubechies 1 book 1 is a standard reference on 
the subjed 

Fundamentals of Wavelet Theory 

This section gives a quick overview of the main formulas. 

The Analyzing Wavelet 

( onsider a complex- valued function v satisfying the follow- 
ing conditions: 



£ 



' . *-' 2w 



hj?(t)rdi < * 



I 



llrjl 



doj < * 



(1) 

(2, 



where W is the Fourier transform of \\\ The first condition 
implies finite energy of the function y, and die second condi- 
tion, the admissibility condition, Implies thai if W(tu) is 

smooth then * (Oi = ft 

The function ^ is the mother wavelet. 

Continuous Wavelet Transform 

If ip satisfies the conditions described above, then die wave- 
let transform of a real signal s(l I with respeci io die wavelet 
Sanction t|j(t) is defined as: 



s„„ if v(L^) 



-'1 'ill. 



(3) 



where v denotes the complex conjugate of y. and this is 
defined on tfee open (bja) half-plane (b E R, a > 0). The 
parameter h corresponds in the time shift and the parameter 
a corresponds to the scale of the analyzing wavelet. 



If we define y x b(t)as 



e-* 'M'-^J. 



,i, 



which means rescaling by a and shifting by b, then eqtiatii m 3 
can be written as a scalar or inner product of the real signal 
stt) v\ith I he function y a j,M ): 



Sil-.ai 



j ,,,. 



Ct)s(t)d( 






When function y< 1 i satisfies the admissibility condition, 
equation 2. the original signal s(u can be obtained from ihe 
wavelet transform SCb>s i b$ the following inverse formula: 



■£t)-i| | S*M*Mt)« 



(6) 



Discrete Wavelet Transform 

In ihe discrete domain, the scale and shiii parameters are 

disereti/ed as a - a" 1 and b - iiU,, and ihe analyzing wave- 
lets are also disci ctized as follows; 



, - nb \ 



" 



where m and n are integer values. The discrete wavelet 
transform and its inverse transform are defined as foll« 



^m.n 



-i 



V'm 



^ V S: 









where k v Is a constant value for nonnalization. 

The fundi- hi ■,■,,, , .. t | provides samph ... ale- 

time plane: linear sampling in ihe time(b-axis) direction but 
logarithmic in Ihe scale (a-axis) direction. 



The most common situation is that ao is chosen as: 
80 = ^ 



Cio) 



where v is an integer value, and that v pieces of y mn (t) are 
j <n >c esse< I as < me group, which is called a voice. The integer v 
is die numbei per octave; ii defines a weii-iempered 

scale in the sense of music This is analogous to the use of a 
>ii of narrowband filters in conventional Fourier analysis. 

Wavelet analysis is not limited to dyadic scale analysts. By 
using an appropriate number of voices per octave, wavelet 
analysis can effect ively perform the I^S-octave, i 6-GCtave 
i n 1 12-oeiave analyses thai are used in acoustics. 

The main torus of current research Lsun (hiding optimal 
wavelet basis functions and efficient algorithms for comput- 
ing the corresponding wavelet transforms. The wavelet basis 
function can be implemented as an FIR (finite impulse re- 
sponse i filter or an 1IR (infinite impulse response) filler 
depending on the particular properties needed. 

Graphical Representation 

This section describes how in display complex-valued 

I linns such as equations 't and S nm that useful iulnnna- 

tion about the signal s(t) can be highlighted. There are two 
Bspi ets to consider. 

The open (h.a) half-plane on which ihe wavelet transform is 
denned can be mapped onto the full plane (b-loguuj. This 
representation is Indispensable if we want to display, in a 
single picture, information with a wide range of scale paxame 
ters. For example, for sound signals in 1 1 le audible range a 
spread often octaves is common. A disadvantage of this 
represent; it inn, 013 the oiher hand, is thai straight lilies OH 
the open fb.aj half-plane become exponential curves m fche 
logarithmic representation. 

Expressions 3 and 8 depend on the cfu >lce « >l the analyzing 
wavelet y. To obtain full quantitative information aboui ttie 
signal s(t) htm ite transform S(h,a) T we need to know the 
analyzing wavelet ^ Their are, however, many features of 

the signal that are independent of the choice otty Such ft?a- 
miV's involve the phase of file complex-valued functions. 

I I < n'fnie, ii is useful to represini separately the modulus 
and Hie pha.se of Ihe complex-valued function Sih.aj to be 

described 

Shown in Figs. 1 and 2 is ait example of the uavelei trans- 
form of a localized pulse thai approximates a delta function. 
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Scale c 



Time Shift b 
Fig* 1. .V];-jjiri:tu<k< of the wavder transform of a delta ftmetim 

The horizontal axis is lime hi both the magnitude picture, 
FLg. I, and the phase picture, Fig, 2. and the vertical axis is 
scale, with small scale at ihe lop. 

hi Fig. 1, the magnitude increases toward the top of the pic- 
ture. The modulus or magnitude, IS(b t a)L is converted to 
grayscale and is normalized to its maximum, that is, the plot 
shows x, where: 



IS1 

ISmaxi 



^ 1. 



(11) 



The phase of S(b,a) is given by a grayscale picture in which 
a phase of corresponds 1 1 1 white mid a phase of 2ji I o 
black. This convention is quite useful in interpreting the 
resulting picture When the phase reaches 2,t, it is wrapped 
around to the value 0. The lines where flic density drops 
abruptly to zero are clearly visible on the picture and play an 
important role in the interp rotation as a visible line of con- 
stant phase, hi Fig. 2, one can sec the lines of constant 
phase pointing to the location of the delta function. 

Examples of Wavelet Functions 

Haar Wavelet The Haar wave! el is the simplest kind of wave- 
let function. Suppose that <J)(t ) is a box function satisfying 
the following: 

Scale a 




Time Shift b 
Fig. 2. I 'I i;\- > ■ i if the wavelet transform of a delta function. 



tftj 



-e 



if : i 
otherwise 



< 1 



If we define the function tjj(t') asty(t) = t)>(2t ) - cpf 2t-l ), we 
can obtain the following function: 



v-n - ^ 



if ii < t < 1/2 
if 1/2 < t < 1 
otherwise. 



The function rpft i is the Haar scaling funrtion, and i^l j is 
the Haar wavelet. This function is orthogonal to its own 
translations and dilations, thai is. the family 



il) mrI1 (U = 2-^iji(2'"t^n) ? m,n 



(M) 



where Z is the real integers, constitutes an orthonormal 
basis for L-(R), Historically the Haar function was the origi- 
nal wavelet. Tins wavelet is no1 continuous, and its Fourier 
transform L Pfo» ) decays only like IcoH, corresponding to bad 
frequency localization. 

Meyer Wavelet, Yves Meyer constructed a smooth onhonor- 
ma] waveln basis as follows. First of all, define the Fourier 
transform <I>(mj of a scaling function <j>(| ) as: 



#(«&) = < 



1 

cos 





|v(Aitoi 

2 \4ji 



-) 



if [ta] ^ =t 

if ^ ^ IojI < |;t (15) 

< itlierwise, 



where v is a smooth function sat isfying the following 
conditions: 



VI 1.1 



if' I < 

1 if t ^ 1 



W itli die additional property 

v(t) + v(l-tj = l. 
Tliis function <J> is plotted in Fig. 3. 



(16) 



(173 



hi this case, the wavelet function \\t can be found easily from 
<fr First, we find the Fourier transform of i|i; 



*y i(u} = gfr>/? y^ <p(io + 242 J + 1) jO(to/2) 



IEZ 



= e k,J ' /2 [0(oj 4- 2jt) + 4>(gj - &#}*{0}/2), 
The function W is plotted in Fig. 4 



CIS) 

(19) 



Now t since ^ is compactly supported ( its duration is finite 
and nonzero) and l ^ E (\ where k Ls arbitrary and may be 
bs (i.e., V has at least k derivatives), y can lie obtained by 
taking the inverse Fourier transform. Fig. 5 shows a graph of 
Hi" Meyer wavelet ip(t) £ C 4 . 

Morlet Wavelet. This particular function was most often used 
hy K. Kronland-Martinel and J. Morlet. hs Fmirier transform 
is a shifted Gaussian, adjusted slightly so that *P(0 j = 0: 



\ a) = e - ll "-^r'"--e-" i2/ -e-"T 1 - 


(20 ) 


t) = (e"'^ 1 - e -1 "- ''-;.-' '" -. 


(21) 



46 Dpi»ptiiIh' r 1 9**4 hVwIptt-Farkarcl Journal 



)Copr. 1949-1998 Hewlett-Packard Co. 



1.2 



to- 



08 



0.6^ 



0.4- 



01 r 



OD 



-Q2 



\2^ 



~6 3 3 6 

I 

Fi#, 3. Faurtei ' nction for rj 

I H'n-u 050 is chosen so that the ratio of the highesl j tuixtun iiil 
of tjrto the second high esr maximum is approximately I 2, 
that is, 



-in 



iJltl J' 1 " - ■ 






In practice one often takes (oq = 5. For this value of (% | ' u ' 
second term in equation 20 is so snialJ I hat il can !>»• ■ 
glected in practice. Consequently, the Mortei wavelet ran 

be considered as ;i \ luiated I raussian waveform Its real 

and imaginary parts l\ n wq -- 5 are shown in Figs. 6 and 7, 
respectively. 

The Muilit wavelet is complex, even though most applica- 
tions in which ji is used Involve only real signals. The wave- 
let transform of a real signal with this complex wavelet is 
plotted in modulus-phase form, ihai is. one plots l{s, it' mi n)l 



M 



3 



1.0 



08 



06 



0,4 



0.2 - 



0.0 



-92 





-0J + 



-1.0 



Fig. 5. Tii- Meyer wavelet. 

and tajr'jlm^s. }$ m n )/Re(s, 1}Wi)Ij where the brackets indi- 
cate the scalar or inner product of the signal waveform s 
with the basis function ijy iui , that is. 



MWi) = 



sU)y' mjl U)dt. 



The phase plot Is particularly suited for the detectii 
singularities- 

Daubechies Wavelet. Ebccepl Rem the Haar basis, all of the 
examples of orthonorma] wavelet bases consisl of infinite^ 
supported ftmctions. ingrid Daubechies constructed an or- 
thonorma] wavelet ta which if is compactly supported, the 

iv a v \*> ensure ( umpaet supporl tor die wavelel ljj is in 
choose a scaling function <p with compact support. 



1.0 



0.5 



- 0,0 



-<1.5" 



-1.0 




-10 



10 



Ki^. T Four! i transform of the Meyerwavete< 



Fitf.fi. Ri -i: part "i the Mori* i wav< lei i"i'W|j = 5. 



iber HUM He* ii-n Packard Journal 47 



)Copr. 1949-1998 Hewlett-Packard Co. 




Fig. 7. Ii!„^;i:„-iry pari of the Slodej wavelet for coq = 5. 

First of all, (ind a progression |a k ;k e Z) satisfying the 
following four conditions for all integer N ^ 2; 



<a -0 ilk < Dork > 2N 



(23) 

,21:. 



k- x 



X Qk = *' Z 



k=- w 



Y P k k m - 0. < m ^ N-l, (26 

where j^ = (-l) k a. k+1 . 

If N = 1, then ot[j = at - L, corresponding to tlie Haar basis. 

We can find a compactly supported scaling function $i i ) 
from the above progression {u k } r The function $(t) is one 
solution o I a functional equation; 



c|)U) = X %^<IPi " k >- 



(27) 



k = 



li is continuous and compactly supported and satisfies 

<!>( t )di = 1 for integer N and the corresponding progression 
[u k j. The support of ip(t) is [0,2N-1]. 

Furthermore, if |> k is defined as tlie condition 26. the function 
ip(t ) satisfying a functional equation 



VU) = V p fc yi^@t - k) 



(28) 



is compactly supported and fulfills the following: 

• v(t )t m dt = for all integers ^ ra <: N-L 

• <p( t ), f (t) 6 C^ Nj for Holder spaces C'< N >, where K(S) is an 
integer parameter and the elements of C }4 ^ ] are functions 
that have /,(N) derivatives. 




Fig, 8. Th'' lJ;uiiHTrii'-s scaling [unction rot N - _:. 

Figs. 8 and 9 show graphs of the Daubecliies scaling function 
(j> and tlie corresponding wavelet tf for the value of N - 2. 

Software Tools: Khoros System 

The vvavr-lH analysis software developed by HP Laboratories 
Japan is implemented as a toolbox in the Khoros sysi< Hit. 
The K h o n >s sy st em is an int e gi at e 1 1 s< i It wa re d e velop i n ent 
environment for Information processing and visualization, 
based on Ihe X Window System. It is distributed in the pub- 
lic domain and has been ported to the HP-UX* operating 
sysienv* 

Khoros components include a visual programming language, 
code generators for extending the visual language and adding 
new application packages to the system, an interactive user 
interface editor, an interactive image display package, an 




-1- 



Fig. 9. Tlie Saubj chies ■■■■ ai elet li ~tt \ = _ 
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extensive library 9* toage pn messing, numerical analysis, 
sigaal processus routines, and iil.v3D plotting packages. 

The Khoros system also supports the toolbox update method 
for new routines created by another person or developed on 
me tfher machine. A (oolhox contributed hv HP Laboratories 
Japan, the HPIJ Toolbox, contains wavelet application de- 
velopment tools, image data compression utilities, and other 
iiTiluies. 

Wavelet Analysis Examples 

The following examples illustrate the advantages of the 
time-scale resolution properties of the wavelet transform 
and a related concept the ekirplet tran^form^ for the analy- 
sis i if various input signals, including a delta function, a 
or box function, a differentially discontinuous function. ;i 
ramp function, sinusoidal functions, a chirp signal, and a 
sum of gliding tonea 

Wa v e I e l Ai i a I y sis 

This section gives several application examples of wavelet - 
based signal analysis, including, both stationary and rkOttSta- 
lionary signal analysis, These results were obtained wiih a 
Mortal wavelet, thai is, a complex sinusoid windowed with a 
Gaussian envelope, expressed as follows; 



r i 



vm = c Kl exp 



H4 






Fig, 10. § 

As for the number of voices discussed earlier, we use v = 6 
in (he following three examples ol synthesized data analysis. 

Example 1. The first example gives the analysis < »f J wo sinu- 
soids. Fig. LO shows a suiusoid with a single constant fre- 
quency, and Figs. 11 and 12 represent its wavelet rransform. 
The horizontal axis is in time in both the magnitude picture. 
Fig. 11, and the phase picture, Fig. 12. The vertical axis is 
scale, small scale at the top. Certain features of the signal 
are evident: horizontal strips of constant magnitude, and 
vertical lines in step with the phase of the signal. 

Fig. 13 shows a sinusoid with linearly increasing frequency 
The wavelet transform analysis results for this signal are 
shown in Rgs. 1 t and 15. Clearly visible is the upward slope 
corresponding to the increase of frequency, 

Example 2. The second example is the analysis of I he super- 
position of two delta functions and two sinusoids. ;ls shown 

in Fig. MJ. One delta function is larger than ihe sinusoidal 

signals and is visible in Rg. ]'>. hm the other is mueh smaller 

,n ,. I iKm-s noi appear. 

Figs. 17 and IS show the wavelet iransfonu representations. 
We can easily see the iwu peaks ai smaller scale that cotire 
spond to the discontinuities contained in the input signal. 

Example 3. This example shows the analysis of a sum of three 
sinusoids with different starting times. The input signal shown 

in Fin 19 la noi discontinuous, hul its lust derivative is. 



where c isa constant value of -^n that the function ip(\) 
satisfies the admissibility condition. 




nme Shift fa 



Fi^J. II 

rin of a constant frequency 
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Time Shift b 



Fig. 12. F 'i 1.1 -- ■ ■ -1 1 1 if m& l>-i 

transform of a constant-frequency 
sinusoid. 




Fig. 10, Sinusoid with linearly 
in<: rinsing nviiU''M \ 




\ 



Time Shift b 



Fig. 14. MaglufcCttie oi £he wavelet. 

T.ran^i'Mii oj a mjiuhukI with 
linearly increasing fei i pien^J 




Time Shift h 



Fig. 15. Phase, of the « 
transform of a ^itysoj i ;: - n li 

linear!; g frequency. 
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Fig. 16* Two ilelia Rmctioi 




Time Shift b 



Fig. 17. Magnitude of the v. . 

fthe sunt of two delta 

Amnions and two dptlSGid 




Time Shift b 



Fig. 18. Phase ol th< .■ i i '■ 
transform of the sum of two delta 
iur i tions and ids. 
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Time Shift b 



Fig, 20, M;mr itude m| 'I' 1 ' " 

" ti i 1 1^-: t = = It r i 0fthre€ - 1 ' ' i :- ' I • 1 ■ v.il|i 

different gtariaftg lii: ■ 




Time Shift b 



Fi«. 2L Phase dfthe mweh i 

i ■-. : i !--"i »r^ti r>|" iliree smih-.-iH:-: \v\\\\ 
(■'Hi '^.!'|.n:i Mm ■ 



Both the frequencies and the beginnings of the components 
are very clearly visible in the wavelet transform pictures, 

Kigs. 2U and 21. A low-frequency sinusoid starts 11 M, followed 
hy a medium-frequency and a high-frequency sinusoid. 

Real Data Analysis* This section shows the results of real data 
analysis. Tins data, provided by the Lake Stevens Instrument 
Division, is the I ransmilier turn-on data of a dual-band trans- 
ceiver that was taken at a cenler frequency of 146.52 MHz 
vvilli I hv nuasuivmint span set to 39.0625 kHz. In other 
words, the data is filtered to approximately a 40-kHz hand- 
width. The lime Interval between points is 20 us. 

The input signal is plotted in Fig. 22, hi this case, the trans- 
form was performed for the value of v = 12. and the magni- 
tude and phase of the wavelet nansfonn are shown in Figs. 
23 and 24, respectively. 



Chirplet Analysis 

The wavelet transform has the effect of dissecting 1 1 u- time- 
scale plane into lime-invariant cells with an aspect ratio 
dependent on the scale parameter. This property is impor- 
tant in spectral processing of signals but does not affect 
dynamic spectrum displays where time I is advanced by 
small increments relative to the cell width. 

The represent at ion of signals may benefit if the cell shape is 
not held time-invariant throughout. This lime-dependent 
a clj u st in e ni can b e pe rf o nned adapti vely. S 1 1 r h a I e< i u i ique , 
called I he rhirpfrt tmwsform, has been proposed. It uses 
oblique cells adapted to the local structure, permitting 
separation of the signal components, 




Fig. 22. Transmitter Tin: 
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Time Shift b 



23. MagniLU 
transi 




Time Shift b 



Fig. 24. Phase ■ 
transform of irai i sn \ it t er 1 1 
data 



The chirplet is introduced as: 



fc.k(t) = e a " Jr cos 



^(f k i + §«?) 



(30) 



where tin ■ ( jjj are tin 1 Hiirplet basis functions, r^ is the fee- 
uuency of * ^ u iS il tneasure of the "sharpness* of the chir- 
plet, and r is a Ere^uency drift rate parameter, The i hirplet 
transform is defined as: 



C(f, 



H 



C k fl - TMljdT. 






Positive drift rale r is associated whh upward sloping 
oblique cells arid the magnitude of r is selected as needed to 
resolvt i ihe st n ict are of interest . 

( onsider a Signal formed by fewd sik < essive gliding lanes 
eaeh of the ft inn: 



E(t)eos 



2^(f,t + i|^ + ^t :1 ) 



(32) 



where E(t) is a rising and falling modulating envelope. An 
example of the input signal is shown in Fig 2 

Figs. 26 and 27 represenl the results of the conventional 
wavelet transform and the Chirplet transform. respe« lively. 
The wavelet transform ran analyze the change of frequency 
of the input signal, but separation of the signal components 
is not possible. The chirplet transform analysis, on the other 
hand, tan separate the two components clearly. 
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Time Shift b 



Fig. 26. Magnitude of Lhe Wavelet 
transform of I lie sum of 1 wo 

Sl|iTI'S-i\r L^li'llllU I ■ ■ I !■ - 






titofti* 



±£i± 



Timet 



Fig, 27. \Li,u,mNkl^ at the ehfrpfet 
Transform of the sum of I we 

'.In ling tones: 
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Approaches to Verifying Operational 
Test Release Vectors 



Five techniques are employed to minimize the time to develop the test 
vectors used to test manufactured parts on an I C component tester, 

by Joy Xiao Han 



in today's competitii ■ computer Industry, the ability to 

accelerate the development process from design to manu- 
factured part in a timely manner is an important tart or At 
HP's Chelmsford systems laboratory one of the things we 
do is design and develop chips for HP 9000 Series 800 
workstations, Among the activities performed during this 
development Ls the generation of a series of test vectors 
called operational test release (OTR) vectors, which are 
used on component testers to verify the correctness of the 
manuf ac t ur v d p aits. 

It typically takes six months to generate and verify opera- 
tional test release vectors. With the techniques described in 
this article we have been able to reduce the Time spent 
creating these vectors to four months. 

Test Vector Development 

The final product of our teat vector development process is 
a set of vectors (also called test patterns) that edit be loaded 
OHIO a tester In Vilify manufactured p;u1s. Physical defects 
thai appear on manufactured parts can be so varied thai it is 
often impract ieal t o try to detect then i directly, 1 1 isi ei u : I . auto 
mark lest generation, waveform creation, and verification 
tools are employed to deal with a logical model of a physical 
defed v\ ho 'h is known as a fault The most widely used 
fault model is the stuck-at fault in which the input or the 
output ofa logic element is stuck at logic or L For exam- 
ple, aii open trace, assuming poshive logic, might exhibit 
itself as si i h k at logic 0, 

Each vcctoi - ilij-n tests a typical block of application logic* 

has at least two parts, One pari is made up of data aiulA>r 
instructions which are applied to the input of the < hip The 
other part, called "expected results," is used for comparison 
with the actual output of the application logic to detect any 
faults. 

The first steps of our test vector deveiopmenl process are 

shown in Fig* 1. We start by using a program called ATP' i 
(automatic test pattern generator) from Crosscheck Corpo- 
ration to produce a file containing the tesi inpui patient 
the fault -free simulation output patterns (expected results), 
and the si au-in and scan -out** patterns for the lesi ]..-> 
ATPG uses a nrcinl model of the chip to determine the 
content of the patterns produced 

n apphMHm lucjn; m Uns paper to mtw to It thai performs 

ihe iriten-ited functions of The component The other logic on the chip is called test logic, which 
is included on ihe chip for tttrfc 
1 Scan m e*pectgd results 
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The next step in our process is to use the ferilpg hardware 
descript ion language ( Vi >rilog HDL) to create a 1 *el m v ioral and 
strut turn! model of the target hardware, The iushuctions in 
i lit- program are structured to icsi the application logic via 
fecial icsi pins collectively called a msi access potl (TAP). 
The 'TAP provides access to test logic circuits that are huiJi 

Into 8 i omponent to icsi ihe component itself and the intl -i 
connections between components. The TAP also provides 
access to circuits thai allow control and observation of the 



I h-i ember J'^'l \\*'\\ I-mi l^nkanl Journal 



55 



)Copr. 1949-1998 Hewlett-Packard Co. 



Overview of the Test Access Port 



Since the emergence of surface mounted devices a great deal of concern and 
tsskwi has gone into determining how to tesi boards crammed with these 
high-density devices, in 1990 Ihese concerns resulted in ANSI/IEEE Standard 
1 149 1 -T99D. Standard Access Port and Boundary -Scan Architecture. Thss stan- 
dard defines test logic that can be included nn an integrated circuit to provide 
standardized approaches to testing the component itself or the interconnections 
between components on a printed circuit board. Hie standard also allows for 
observing or controlling the behavior of a component during its normal operation 
The test logic allows test instructions and test data to be fed to a component, and 
upon execution of an instruction, allows the results to be read nut and Dbs-- 
Ail instructions, test data, and results are communicated in ser-al format. 

The test Jogrc defined by the standard consists of a chain of boundary-scan ceils 
and test support logic, which are accessed through the TAP inputs (see Fig i j A 
boundary-scan cell is a shift- register stage that is connected between each [flpu'l 
or output pin on an IG and the application log?c to which each pin is normally 
connected (see Fig, 2). The scan ceil has two states of operation One state allows 
a sequence of bits representing data and instructions to be shifted (scanned-in) 
mto a chain of scan cells, resulting in latching each cell to the rJesfffid value The 
scan-in and scan-out lines shown in Fig. 2 carry the bits from one cell to another 
The logic specified in the standard is designed so that the serial movement of 



i.-istrjctinn data is not apparant to the circuits whose operation is controlled by 
the instruction. 

The other state of operation for the scan ceils involves testing the application 
logic. The test operation involves either receiving test data from the application 
Jogic via the signal -in line and then latching the output or shifting test data into 
the application logic via the signal-out line. The test logic is specified such that 
the movement of test data has no effect on the instruction present in the test 
circuity 

After the test state is done the scan mode can be invoked again to shift out the 
fatched test results far comparison with the expected results 

The clock, shift, and mode lines shown in Fig. 2 are controlled by the TAP signals 
(described belowk The TAP lines are responsible for sending the proper signal 
sequences to control the scanning or testing states. In addition, the mode line is 
controlled according to the type of pin it is connected to (e.g.. input, output, 
bidirectional, tristate, etc.) 

The IEEE standard defines a minimum of three input connections and one output 
connection (see Fig 1) An optional fourth input (TRST) provides for asynchronous 
initialization of the test logic circuitry defined in the standard 
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Fig. 1, A BfmpKfied block diagram of the 
test logic defined in ANSiyi££E Standard 
1149.14990 surrounding application logic 



application circuits during their normal operation. The 
specification for the TAP logic is given in IEEE Standan I 
1 148, W99Q, and a brief overview is provider! above. Also 
included in Ihe Verilog HDL model are calls to a utility called 
Stds_monitor(p which associates liming information with the bit 
patterns sent to Ihe device under test. These calls will create 
a raw w avefonu database containing timing and pattern 
information. It is called a raw waveform database because 
during simulation runs every change on the component's 
pins is included in the database. One of the techniques de- 
scribed below explains how this data is manipulated to 
produce a more refined waveform database. 

The third step shown in Fig, 1 involves running the Verilog-XL 
logic simulator using the Verilog HDL model created in step 



2 and the patterns created in step 1 ;is inputs, A waveform 
database and an output pattern file are created from this 
simulation. The output patterns from the simulation are 
compared to the expected output patterns generated by 1 1 lp 
ATPG software. If the patterns don't malrh, steps 2 and 3 
are repealed until ihey do, If the patterns do mairh. we 
move on to prepare the waveform database to become our 
operational test release \vi -u us. 

A great deal of time can he spent going back and forth be- 
tween steps 2 and 3, The rest or this paper describes some 
r- - hniques that 1 have found lo be helpful in getting through 
steps 2 and 3 quickly. These ipchnitjiies verify that, the TAP 
ci ic 1 1 its are funct ioning p rope r ly . 



ITil stds.monitort) runs as part D-f the Vari tog-XL simulator. 
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Fig, 2. Ths ocattan of scar. Dfirtls in n- pins sno trie application ivigjc The mode, cferck and shift signafs are cJenved from the TAP input signals TMS. TCK. ar>d TflST* re?" 

Tni 1 rc i scan-In signal and the last scan-out signal correspond ha TDI and TOO respectively. 



Tesl Clock. TCK is the test clock input that provides the clock far the lest logic This 
clock is provided so that scan cells surrounding the application logic can be con- 
trolled independently of system docks. TCK allows shitting of test data concurrently 
with system operation (allowing online monitoring! It also ensures that test data 
ran be moved to or from a chip without changing The state of the application logic. 

Test Mode Select, TMS is the signal used by the TAP controller to control test 
operat ions . On e u s e of T M S i s to select whethe r The te si "the tes I 

state or the scan state. To guard against race conditions, the TMS s^nal Ilka ttai 
TDI signal described below must be sampled on the rising edge of TCK 

Test Reset. The opt iu rial TRST* signal is included to allow for asynchronous reset 
TAP controller The reset signal onry affects the test I ogre and has no impact 
on the application logic, 



Test I/O Lines. TDI and TDO are the test data input and output lines respectively 
They provide for the serial movement of test data through the circuit. Data pre- 
servted at TDI is clocked into the selected register on the rising edge of TCK, while 
output data appearing at tdo is clocked out on the falling edge of TCK To simplify 
the operation of components that are compatible with the standard data must be 
propagated from TDI to TDD without inversion 
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Technique 1 

Check the scan chain" without a system clock. Tills step i^ 
mainh used to make sure thai the scan chain on the chip is 
not broken. This test works by ensuring that whatever value 
is scanned in (Si in Fig. 2 1 should be exactly Identical to the 
value scanned out (SQ). The scan dtaln is advanced by clock 
pulses For example, a pulse from CLKA followed by a pulse 
from CUB causes the data oil si to be propagated to SQ, SO 

tums into I he SI for the next scannable tlip top on the SC0E 
chain. If the clap passes this test, we know that i he scan logic 

is set pi j .. -i-[y and I hat there is continuity in the scan chain. 

Technique 2 

Check the scan chain with a system clock. This check verifies 

thai riu combinational togic in the application logic pciiUoa of 

' A scan i • i agister oatti through a nrcuit which is typically placed rhere to improve 

testability, Sei ■ $ :he Tusr Accass ^ rl 



the chip works. Usually the master dock {MCLK} is opposite 
iu state to I he system clock (CLK) (i.e., When CLK is on. MCLK 
is uiTand vice versa/. The i ri!\ exception to this behavior 
occurs when we execute* double-strobe tesl to cheek the 
time margin on the chip. 

The opposite clock states are verified by ensuring thai the 
data on the D input in Pig. L which is l lie result of all pre- 
vious combinational logic, is inverted at MQ when CLK is tow. 
On the other hand, when CLK is liirned nn. the im cried value 

iiCmq (ilie exact value of D) appears ai a. This is the same 
value W'C can monitor ai SQ by advancing the scan chain 
with poises Ijoiu CLKA and CLKB in the coneci sequence. 

Technique '4 

Check the TAP state sequence Since the TAP logic m bs m 
cally a stale machine Hs current state Is recorded in a mode 
: i, 1 have found ii necessary io iuiy attention to ttie 
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Fig. 2, Sr:uiui;.ibW* flip-flop. This 
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pi e\ ions stale of the TAP circuit by checking certain bits in 
the mode register' For example, one error that typically 
takes a long time to correct occurs when the bit in the mode 
register that controls I/O direction (PSCAN in Fig. 3) is not 
set properly during initialization. Forgetting to set tins hit 
causes TSTDEN (test data enable) to go high dining a scan. 
Later when data is supposed to be coming out of the chip 
(via the I/O pin) and the tester is driving a value into the 
chip, a bus fight occurs. We want TSTDEN to be low, which 
puts the gate in tristate mode when the tester is d riving a 
signal onto the pin. Anytime the wrong data is output be- 
cause of something that Is done or not done early in the test 
cycle, it always takes a long lime to debug. Debugging time 
can be saved if each state (bits in the mode register) is 
closely monitored. 



The first thing we do is take the raw waveform database 
described above and use the conditioners- 1 ALIGN and 
WINDOW to create a more refined waveform database. We 
use ihe AIJUN conditioner to align each signal to be edge 
triggered The WINDOW conditioner is used lo select certain 
cycles or windows within a cycle during which uutpul data 
is valid, which results in monitoring pins only ai ihe limes 
we care about. The next step Ls to verify that the windowed 
data is okay. This involves the same process we went 
i h rough in steps 2 and !J of Fig, 1. If everything is okay, the 
waveform database is converted to OTR vectors to run on 
the tester 

' Conditioners sre functions that provide a way to modify waveform data generated via 
Srds_ monitor. The ALIGN and WIN DOW conditioners come from TSSI Inc. 



Technique 4 

Check the value of each pin before each system clock. One 
bug that occurs frequently is that test vectors will run 
smoothly during simulation, but cause hus fights when they 
are run on I lie tester Front Fig. 3 we can see that if BUS IN 
and the tester drive an identical value onto the I/O pin at fefee 
same time, a problem occurs that can only be caught by ihe 
tester and not by simulation. This problem can be eliminated 
if w r e stop the simulation before each system clock and 
make sure thai Ihe I/O pin is driven by either BUSIN when the 
pin a< Is as an output ( Lc ., the pins drive the values to the 
BUS OUT), or by Ihe tester when Ehe pin acts as an input, but 
not both at one time. This task can be easily accomplished 
by using the Verilog-XL command Sshovwars. 



TESTER 
DRIVING 



r PSCAN „ J? .™ 
_ / Mode 



~b?i 



I/O Pin 




BUSIN 



~> BUSOUT 



Technique 5 

Verify that the process of creating the operatic naJ test release 
I MR] vectors for ihe tester is correct. Fig. 4 shows the addi- 
l ional steps we take to create and verify the OTR vectors. 



TEST0EN = when TESTER DRIVING Is Sending Input la I/O Pin 
a 1 when BUSIN Is Sending Output to I/O Pin 

Fig, 3, A simplified diagram of the circuitry around an I/O pin 
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Fig, 4. Tin- final • 



Con elusion 

These five techniques have proven to i i the 

Chelmsford systems lab by shon time ft takes us to 

produce ft nal test vectoi i edmiques can also be 

applied to non-ATPG ( )TR wrt< as, since we can create vec- 
tors inajuially to meet different needs and put them into 
ATP< i format. We characterized the entire analog circuitry 
embedded in one chip by controlling the proper bits on die 
scan chain. 
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Estimating the Value of Inspections 
and Early Testing for Software Projects 

A return-on-investment model is developed and applied to a typical 
software project to show the value of doing inspections and unit and 
module testing to reduce software defects. 

by Louis A. Franz and Jonathan 0< Shih 



The software inspection process has become an important 
part of the software development cycle. ] ■- •■* A and has been 
used with vailing lewis of success within Hew Ihi -Packard. ir ' 
One of the main reasons for its success is that delecting 
defects early has a big impact on reducing d ie cost of dealing 
with software defects later in the development cycle. One 
HP entity used metrics data from several software projects 
and an industry profit and loss model to show the high c< >si 
of finding and fixing defects late in the development cycle 
and during postrelease/" 

This paper describes the methods we have used to integrate 
inspections and prerelease testing into the development of an 
information technology software project. The metrics col- 
lected and the tools we used to rolled lire metrics data on 
Mi is project are described. Finally, we describe an approach 
to using the met lies data collected during inspections and 



testing In estimate the value (return on investment) of in- 
vest mg I ime and effort in early defect detection activities. 

Background 

The sales and inventory tracking (SIT) project evolved from 
separate initiatives by several different groups in HF J These 
initiatives had different objectives, but all relied on elements 
of the same, data: computer dealer sales and inventory levels 
of HP products- To simplify the collection, processing, and 
storage of this data, it was decided to create a centralized 
system to house the data All the applications I ha I would 
m ed to use this information could access the central SIT 
system database. Fig. 1 shows the four major modules that 
make up the SIT system and the major data stores accessed 
by (he system. These modules will be referenced throughout 
tiiis paper. Table I provides a summary of the major attributes 
of the system. 
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Table I 
Summary of the Sales and Inventory Tracking System 



m type 
HanJ ware platform 

Language 

MS 

Data communications 

: for the electronic 
transfer of dal a 
the dealer am 'i 



Data access and 
manipulation tools 

Code 



Batch 

HP es 980 running the 

MPE/XL operating system 

COBOL 

HP AllBase/SQL ( n 

Electronic Data interchange 
(EDI) ANSI standard trans. 
tti >n sets < flit 1 formats): 
867 product transfer and 
resale n\"m 
inventory Inquirj 
advice 

Cognos, PowerHouse (Quiz), 
Superior. KSAM and VPLl'K 

j oral Lines of source code 



" KNCSS - Thousands qf rrancommfflil source statements 

We used the traditional HP software life cycle for our devel- 
opment process. The basic steps of this process include: 

• Investigation 

• Design 

• Construction and Testing 

• Implementation and Release 

• lV>stimplerneniation Review, 

The inspection and prerelease testing discussed in ibis p 
occurred during the design, construction, and testing phases. 

Inspection Process and Inspection Metrics 
The objectives <>\ the inspection process are- to find en 
earfe In the developmenl eyrie, check forconsistencj with 
codmg standards, and ensure supportabflity of the final 
cmU- During the course of < mulueting inspections for the 
SIT prujei t, we modified the HP Inspection process to meet 
our specific needs. Table II compares the recommended IIP 
inspection process with our modified process. 

Step 3 wn> changed to lssn< and Question Logging because 
we found dim inspectors often only had questions aboul the 

i U n imuiit under inspect* m, and authors tended to feel more 
comfortable with The term issue rather than defect The 

Table II 
Comparison of Inspection Processes 

Step Our Inspection Process HP Inspection Process 

Planning Planning 

1 Kickoff Kickoff 

i Preparation Preparation 

3 Issue and Question Logging Defeci Logj 

4 Cause Brainstorming Canst 1 Brainstorming 

5 Question and Answer Rewurk 

S lie work Follow-up 

7 Follow-up 



term defect seemed to put the author on the defensive and 
rely limited the effectiveness of the inspection process. 

The Question and Answer step was added because inspe< 
often had questions or wanted to discuss specific issues 
during the Issnr and Question Logging session, These ques- 
tions defocused the inspection and caused the process to 

take loiiL 

e Planning step the author and the n : »l;m the 

inspection, including tl ion coal, the comp 

the inspection team, and the meeting time. Tlie Kickoff step 
is used for training new inspectors, assigning the roles to the 
inspection team members, distributing inspection materials, 
and emphasiz ain tocos oft! - i ss, 

During the Preparation step, ins independently go 

tin ough t: ■ I ion materials and identify as many defects 

as possible. In the Cause Brainstorming step, inspection team 
members brainstorm ideas about what kind of global issues 
might have caused tin- defects and submit suggestions on 
how to resolve these issues. During the Rework step, the 
author addresses <n Efopes *n-er\ issue that was logged during 
Step 8, Finally, in the Follow-up step, the moderator works 
with the author to determine whether every issue was 
addressed or fixed. 

Along wiili the modified process, a one-page inspection 
process overview was generated as the training reference' 
material lot the project team. This overview was a very con- 
venient and useful guideline for the project team because ii 
helped to remind the team what they were supposed io do 
tor ( m h inspection. 

Deciding What to Inspect 

Because of time ami resource constraints, not all of the 
project's 13 source programs and 29 job streams could be 
inspected. The project team decided to use the risk&ssess- 

n( done for the master lest plan, which uses the opera- 
tional importance and complexity ■ A' a mm »dule as a basis f< ir 
deciding which programs and job streams to inspect The risk 
assessment used fertfce master feest plan is described later. 
Fig. 2 shows thr results of this selection process in nuns of 
inspection coverage and relative levfcl of complex^ of the 
programs ind job si reams. 

Inspection Metrics 

Three forms were used to collect inspection metrics: the 
inspection issue luu, the inspection summary hum, and the 
inspection data summary and analysis form. Fig 3 shows an 
inspection log and an Inspection summary form. 



Test Plan 

and 
Test Script 
Inspected 



Percent of 
Programs 
Inspected 



Percent ol 

Job Streams Relative 

IJCU Complexity 

Ins peeled 




* This module consisted of only one JCL and one program. 

Fig, 2. Inspectiof! •■■■■ <\ a$ Fot them^joi modules in the SFT a# 
baaed on the criteria used in the master plan 



IJrr.-tnlir! I! 1 !'] Itru[i'i(<[*;i( kinl.IoUCTtill 



61 



)Copr. 1949-1998 Hewlett-Packard Co. 



Inspection Issue Log 



Page of 

Document Inspected. 



Inspection Date. 



Page# 

Line* 



Issue 
Description 



Type 



Severity Resolution 




Type; (SI Specification 
ID) Data 

ISO I Standards Deviation 
|R) Resources 

Severity: <C) Critics! 

(E| Enhancement 



jDLf Design Logic 
|M) Miscommunication 
<QV) Oversight 
(Ok Others 

(N) Non-Critical 



(a) 



Inspection Stimmarv 



Inspection Date: 

Kick off Meeting: 

System or Project Name:. 
Dacumeni Inspected: 
Preparation Time: 



Type of Inspection: 
(Circle ihe Type) 



Stan Time: . 
Finish Time: 



Moderator 



Reader 



Author 



Total 



In spector 



[nspecloi 



Inspector 



investigation 

Coding 
Documentation 



Approximate Document Pages 
or Program Lines inspected: 
Number of Critical Issues fCI 
Specifications 

Design Logic 

Data 

Standards Deviation 

Miscommunication 

Oversight 

Resources 

Other 

Total: 

Number of Enhancements 



Prototype 

Test PJan 

Other 

Pages 



ES 

Install at ion 



IS 
Release 



NCSS 



(S) 



(DL) 



M 



(SD) 



JM> 



<0V ) 



w 



{0} 



Number of Noncrittcal Issues [H\ 
Specifications 

Design Logic 

Date 

Standards Deviation 

Miscommuntcalion 

Oversight 

Resources 

Other 



(S) 



(DM 



M 



ISO) 



m 



[OVf 



w 



joj 



Total: 



(£} 



How many times was this document inspected? 
How many times was this document postponed? 
Why was it postponed? 
How many peopte were asked to participate in (fie 

inspection but refused? 
Totaf time author spent to fix or address all defects: 
Total time moderator spent to follow up with author; 



lb) 



Fiu;. 3. ':i I fesperitel festte \o$. (b) Inspection summary form. 



The inspection issue log is used for logging the issues ob- 
server! by lite inspectors during the Issue and Question 
Logging session, The inspection summary tl escribes the doc- 
ument inspected, The inspector's preparation lime, the type 
of inspection , the number of pages and lines inspected, the 
number and types of delects identified, and the total time 
used to fix or address all the defects, The inspection data 
summary and analysis Form is a spreadsheet that was used 
to collect the data entries required to calculate inspection 
efficiency, inspection effectiveness, total time saved, and the 
teliirn-on-investment value (described later). Table 111 lists 
the data collected in the data summary and analysis form lor 
each item inspected. 

We selected four key inspection metrics to measure our in- 
spection effort: number of critical defects found and fixed, 
number of noncriticai defects found at id fixed, total time used 
by inspections, and total time saved by inspections. 

Testing Process 

Our testing process included test planning, unit testing, 
module testing, and system testing. Test planning involved 
creating a master test plan and doing a risk assessment to 
determine where to focus our testing time. 

Master Test Plan, A master lesi plan was created during the 
design phase when the test strategy tor the project was out- 
lined {Fig. 4 J, The master test plan included the test plan 



design and the type of tests to be perforated. For design 
purposes, the system was divided into logical modules with 
each module performing a specific function (see Fig. 1 ). The 
lesi design was also oriented around this division. 
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Fig. 4. Master test plan organize ii 1 1 
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action time 

Delects 

mentation type 



Table III 
Inspection Summary and Analysts Data 

Units or Source o! Data 



aration and meeting time in 
hours 

Number of critical and noncririca] 

defe 

requirements and design 
specifications, manuals, test 
plans, job streams [J< L), and 

r documents 



i «i document 

Amount inspected 

Preparation rale 

Logging rate 

Moderator follow-up 
time 

Time t o fix a deled H o urs 

Total lime used 

Time saved on critical 
defects 

Time saved on mm- * 
erilieal defects 

Total time saved 

Return on investment '■■ 



KNCSS for code and number of 
pages for other documents 

KN<; SSor number of pages 
inspected 

= (number of pages) x (number of 
people /preparation time 

= (critif al - lmiu -ritk-al defects)/ 
(hours/number of pei >ple) 

Hours 



- inspection time - time to fix + 
follow-up time 



Def in-e-i \aiB( in this article 

The primary and -sr* undary features l<> h< tested were abo 
Included in the master test plan, The primary features were 
tested against the product specifications and the accuracy 
of the data output. Secondarily testing was performed tQ 
ensure optimum speed and efficiency, ease of use < nsvr 
interface), and system supportability, 

Risk Assessment. A risk analysis was performed to assess the 
relative risk associated with each module and its compo- 
nents. This risk analysis was used to help drive the schedule 
and tower-level inni and integrated rests. Two factors were 
used in assessing risk: operational importance to overall 
system functionality and technical difficulty and complexity 
Each module was divided into sulmiodules and rated against 
each risk factor, For example, the proper execution of the 
logic in submodule L2 was critical to the success oi the sys- 
tem as a whole, while submodule I A merely supplied addi- 
tional reference dala to the database At < nrdiugly module 

1 j received a hiy\er operational importance rating. Simi- 
larly, * l module 4.2 also received a lug! hi complexity rating 
because ofthe complexity of the coding task it entailed. 
Badi rating was based on a scale of one to five with one 
being the lowest rating and five being the highest niling. 
Is 1 ; mugs foi each risk factor tim then combined to gel an 
overall risk rating for each submodule (Fig, 5). 



Module 


Submodule 


Operational Technical 

Importance Drtticalfy 


Overall ftbfc 
Rating 


1J 


1.1 


5 1 


i 




u 


5 3 


I 




u 


5 3 


8 


1.4 


1 1 


2 




13 


4 3 


7 


zi 


IJ 


3 2 


5 


ZI 


b 2 


7 




22 


5 3 


■ 


xo 


3.1 


5 4 


9 
7 




22 


5 2 




32 


3 2 


S 




3.4 


5 2 


7 




35 


4 5 


9 




3.6 


1 1 


2 


4.0 


41 


5 3 


8 




42 


5 5 


10 




4.3 


5 4 


9 




4.4 


5 3 


8 




4.5 


3 Z 


5 




4,6 


2 4 


6 




4J 


1 3 


4 



Fig. 5, Risk ratings i.-, aubmoj 



Unit Testing. Unit Jesting, as in most software projects, was 
performed for all programs and job streams, For the purpose 
of this prpject, each individual program and job stream was 
considered a unit Since programs were often embedded in 
job streams, program unit bests were often synchronized 
wilh job stream unit tests to conserve time and effort, 

ise of the stnajj stee of the project team, almost all 

tests were performed by the program or job stream author, 
To minimize the impact of tins short corning, a simple testing 
review process was established, A series of standard forms 
were created to document each test and facilitate review hv 
the designer, users, and Ihe project lead at different points 
in ihe unit testing process (see Fig. 6), 

Module Testing. An integrated test of all programs and job 
streams within each module was conducted fcotesil tfjeov&r- 
afl functionality of each of the four system modules. Since 
each program or job stream had already teen tested during 
Mini lesting, the primary focus of module testing was on ver- 
iryingthat the units all functioned togetharproperiy and that 
the desired end result of the module's processing was 
achieved. 

A brief integrated iesi plan document was created for each 
module. This test plan listed ihe features to be tested and 
Mutinied the approach to be used. In addition, cor up let ion 
criteria, test deliverables mid required resources were 

documented | 

Deiailed test scripts wire used lo facilitate each module fcesl 

and make il easy In duplicate or rerun a | >aH iriilar lest. Each 
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Unit Test Case Worksheet 



Module Unit: 4 2 
Program/Screen/Job Name: 


SIT40Z3S 


VALID Input Conditions 


INVALID Input Conditions 


Loc_hdr.fd_code<>9 


No transaction header 


Quantity qualified = 14,17, 7G 


ANSI code <> 867, 846 




Tx^count = spaces 










^^-— "~~" ^ ^~^^_ 




sJ 



Unit Test Script 



Module Unit: 4.3 

Program/Screen/Jab Name; SIT 403 IS 
Script #: 

Procedure 



(1) Set file equations 



{2\ Run program, parm = c 



(3) Verify file layout matches 



Resources needed 



Programs: GEtPROD 



Screens: 



Database: SITDB, PRIME 



SITDB Tables; Outlets, Channel,. products 



Others 



Unit Test Case 



Module Unit: 4.2 

Prog ram/Sere en/Job Name: SIT 4020 J 

Script #: 

Pass<Ye$)/No 

Case Description 



Date Inspected: 5/4/92 



Verify that locations with missing elements are reported. 



Input Conditions 



Outlets table "business.narne" blank DID = 0671 100920 



End-user table "company" blank DID - 0671 1D0T IS 



Output Conditions 



OID - 0671 100920 appears on report 



DID = 0671 10D1 1 S appears on report 



Special Requirements 



Use test file TST40207 TEST. SIT 



Fig. 6. Unit n-st fun us. 

Feature to Be Tested 

• Module processes run correctly when run in production order 
» Module processes run correctly with actual production data 

• All programs, JCLs, screens pass data to next process on timely basis 
Approach 

* Set up production test enuiranmenl 

• Stream JCLs, run programs, and execute entry screens in production order 

• Use production data 

* Verify subsets of key table data after each process 
Completion Criteria 

* All programs. JCLs, screens run without error or abort 

* End result of process is correct data loaded into Product, mix, Product exhibit, 

Channel products, Customei Products, and Customer EkhiluiH Tables 

Test Deliverables 

• Test script 

* Test summary report 
Resources 

• Staff - Lou, Shrtpad, Jill 

* Environment 

Jupiter SIT account 

Blitz - Paisy OS I PATS Y##. PATO TA M AS | : M ode 5 
Prime DH fPR!ME3##.PR3DTA,MAS):Mode6 

Fig. 7* A | u->rl if i] i of m i fctfci ■■. I j >lau 



test script document included a listing of the resources 
needed for the test, such as supporting databases, SIT data- 
base tables, files, file equations, programs, and a step-by- 
step procedure for executing the test. Where appropriate, 
specific data to be entered into the system was included in 
ihe procedure. Also included were Ihe expected results of 
each lesi step and the overall test 

Once the integrated module tests had been completed suc- 
cessful ly (often this took several iterations), a rep oil detail- 
ing the test results was created. The integrated test report 
documented Ihe number of times the test was run. verified 
that the completion criteria were met, listed the number of 
critical and noneritical defects detected, and verified that 
each defect had been fixed. 

System Testing. System testing w^as conducted in tandem 
with a pilot test ai an HP dealer. Initial values were entered 
for the general-purpose database tables and for the dealer 
involved in the pilot test Production schedules were used to 
control the job streaming that executed the system. 

Testing Metrics. 'i\vo kinds of metrics were selected to mea- 
sure our testing effort: total number of critical defects and 



'it 
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total testing lime for each test phase. Table IV summarizes 
our test metrics for unit and module testing. One critical 
defect was found during system testing and the total system 
test time was 19 hours. 



Testing RQJ = Tula! Time Saved h\ I nir 
and Module Testing Total Time Used 
by I "nit and Module Testing. 












Table 


IV 












resting Metrics 






Module 


Size* 




Unit Test 


Module Test 






T c 


N c 


(ATT) C 


T t 


u t mk 


1.0 




" 


4 




41 


7 5.86 


J.n 




. 







** 


** ** 


3.0 


3516 


31. 


i 


LOJ 




in 


4.0 


3738 


35 


21 


L67 




13 i 77 



1 NoncOTiirtenl source /"SSI 

' Not amicable 
\ = Total testing time Taf CfftM defects Jn hour s 

N c = Total number ol critical defects 

- Average testing time per critical defect = VN C 
Is defined' as zero when U t is zero 

Return-on-Investment Model 

ft is now generally accepted that inspections can help soft* 
ware projects hi id defects early in the development r\cle. 
Similarly, the main purpose of unit and module testing is to 
detect defects before system or pilot testing. Questions that 
often route up regarding these detect finding efforts include 
how much project time they will consume, bow effect ive 
they are, and how we can measure their value. Must of 
these issues have heen addressed in differeni ways in the 
lileraturr. '■ ■' 

In this section we present a return-on -invest mei 
model we used to measure the value o! inspections and 
early testing in terms of time saved land early to markei ). 
The whole idea behind ihis kind of ni< ssur< sm -m is thai it 
should lake longer to find and fix a defeel ai system test 
than N does to Bnd the same defeel during inspection or unit 
testing. This means thai foreveij defect found during an 
inspection oral an earlier Stage of the testing phase, there 
should be a tote savings realised at the system test phase. 

First we define the Ftarelesse ROIasi 



Prerelease ttoi = 

IbtaJ Tune Saved Total Time I 



,1, 



where: 



Total Time Saved = Total Time Saved by Inspection f 
Toml Time Saved by Unit and Module Testing 

and 

Total Time Used = Total Time I'sed by Inspection + 
IbtalThne Dsed by Hut and Module Test I 

We calculate the individual R< )\ for inspection aiid testing, 
respectively as follows: 

Inspection ROi = Total Time Saved 

by Inspe. lion Total Time Used bj Inspection J. 



measure nol only how much time was being 
spent on inspection and testing but also how much time was 
being saved as a result of the defects found during insp 
tions and unit and ma sting. 

The " during ait inspection includ m of the 

total inspection time spent by each team member, the time 

speni by the attdtor on Fixh i - ind the t 

by the moderator Following up on defect resolution with the 

author. 

For inspections, we defined the total time saved and the 
ft <ial time used as: 

Total Time Saved by Inspection = Time Saved OH 
Critical Defects + Time Saved on Noncritical Defects 

Total Time 1 sed by Inspection - Inspection Tlnte + 
Time to Fix and Follow up for Delect Resolution 

where the critical defects are defects that affect function- 
al i i y and performance and noncritical deli II oi her 

The time spent rinding and uxmga critical defect at system 
test is railed I IK' I (black box testing rime). Therefore, for 
every critical defect found before system test. Hie loial lime 
saved can be calculated as follows 

Time Saved on Critical Defects = BBT x Number of 
Critical Defects - Total Time I ."sed. 

The mod el we used to measure noncritical detects is based 
oil the assumption thai noncritical defects could be found 
b\ inspection but would not be detected by testing. The itoh 
cj inca[ delects \\ ill become supportabihtj issues after man- 
uJVh luring release. We defined a new variable called MTTR* 

I iiiiiiti total lime to rework ) to measure Ihe lime speul mi 
noncritical defects, 

MTTR - Time to Find Defect + Time to Fix I fefed + 
Time to Release to Prodi* -tion. 

Thus, 

Time Saved on Noncritical Defects - MTTR x Number 
oi Noncritical I >efeets, 

Fot lesiini: mi inrs we wanled I o measure nol only how 
i m irh l irne was being spent on unit and module testing, bill 
ulsu how much time was being saved as a result Of the de 
feels found during these tests. Thus, wre defined thr total 
time saved and total time used for testing as; 

Total Time Saved s Time Saved on Critical I »ei 

Total Time Used = Time to Design and Build a Tesl f 
Tim*/ to Execute + Time to Find and Fix a Defect 



1 We used an ci • ■ • hours for MTTfi in our calculations 
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The defect data and time data for our sales and Inventory 
tracking project nn summarized in tables Vand VI 



Table V 

Defect Summary for the Sll 


' Project 






During 
Inspection 


During 
Testing 


Total 

Prerelease 

Defects 


Number of Critical De- 
fects Found sand Fixed 


12 


5 J 


ti;J 


Number of None til tcaJ 
Defects Pound and 

Fixed 


78 





78 



Willi the rode size equal to 13,0 KNCSS, prerelease defect 
density - 1411!'; = J0,4 delet i^/KNCSS, 

Using the model described above, we can calculate the ROI 
values Shown in Table VE 

Total Time Saved by Inspection = (20 hours x 12} + 
[6 hours x 7K> - ( 10 hours - 708 hours** 

Total Time Saved by Testing = 20 hours x 51 - 310 = 710 
hours* 

From equations 1,2, and 3: 

ROI for Inspections = 708 / 90 = 787% 

R< )l for Testing = 710/ 310 = 229% 

Prerelease Ibtal ROI - 1418 / 400 = 8$!$$. 

Table VI 
Time Data and Return on Investment Results 





Total Time 


Total Time 


Return on 




Used {hours} 


Saved (hours) 


Investment (%) 


Inspet lion 


90 


708 


787 


Testing 


310 


710 


229 


Prerelease 


400 


141S 


m 


Total 









ia- 
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<X 
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^v 
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^v 
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^v 






^v 
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\V 
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S3 
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Results 

Fig. 8 shows that with the exception of module SIT4.0 the 
average testing time per critical defect decreased from unit 
lest I o module (est for the system's major modules. The rea- 
son that il took 19 hours per critical defect at system test is 
mainly the Time it took to Hud ami fix one defect that was 
overlooked dining inspection. Had the project team not over- 
looked one particular issue related to product structure ilia! 
resulted in this defect, the average testing time per critical 
defect at system test would have been sign if! candy lower 

Module SIT4.0 went through the most thorough inspection 
including a design Inspection since it is the most complex of 
the four modules. We helieve our efforts paid off because it 
took less time at unit test and mo* i tile test in terms of aver- 
age testing time per critical defect for module SIT40 than 
for the other three modules. 



Unit Module System 

StTl.flO SIT2.0A S1T3JJO S1T4.0D System* 

Fig, 8. Testing lijiu-' by test ph&se mui module 

Fig. is a plot of I lie ROI column in Table VI. It shows that 
inspections have resulted in more than three times die ROI 
of testing. This reinforces the notion thai a great deal of 
money and time can be saved by finding defects early in the 
software development cycle. 

Lessons Learned 

The inspection and testing pn icesses we uyrd for the SIT 
project are not very different from other soft wh re projects 
in HR However, we did put more emphasis on early defect 
detection and collected a lot of metrics. The following are 
some of" the lessons we learned from our efforts during this 
project . 

Project Management Some of the lessons we learned about 
projeci management include: 

• Setting aside lime for inspections and thorough testing does 
Hay off in the long run. Management approval may be diffi- 
cult to get, especially when under Intense lime pressure. 
One should get commitment to delivering a quality product, 
then present inspections and testing as pair of delivering on 
thLscujiiniitmenl. 

* Keep high-level test plans short and simple while still pro- 
viding enough direction for the lower-level plans. By keep- 
ing these plans short and simple, time will be saved and the 
projeci team can still get adequate direction, 



1,000 



_80fl 

i 

s 

E600 



400 



200 



l 



L 



Inspection Testing Prerelease Total 

Fig. 9. Relative impact ofinspei m rts m; testing. 



1 The time to find and f k a critical defect during system test at HP ranges from 4 to 20 hours. 
We used 20 hours in ou* ROI calculations. 
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• Adequate follow-up to inspection and testing activities is 
important to make sure all issues are resolved. The inspec- 
tion log. testing error logs, and integration lesi reports 
helped the project lead keep up on the status of each issue 
and ensure (hat each issue was resolved, 

• Establish coding standards at the beginning so that mini- 
mal time is spent during code inspections questioning 
points of style. The focus of code inspections should I te 

functional] ly. 

Inspeclion. Since die inspection process is the most iinj 
taut tool for defect-fir e, many adjustments were 

made h> 

• Attitude is the key to effective inspections. No one mites 
error-free code, but many people think they do. Authors 
must realize that they make mistakes and take the attitude 
thai they vvant inspectors to find these errors. The inspec- 
tors, on the other hand f can destroy the whole process by 
being too critical. The inspect ore must keep the author's ego 
intact by remaining constructive. Perhaps the best \va\ to 
keep peoples attitudes in line is to make sure they know 
that they may be an inspector now, but at a later date, their 
role and the authors will be reversed. For this reason, im- 
plementmg an inspection process for most or all of a proj- 
ects code is likely to be much more effective ihan random 
inspection of a few programs. 

• No managers should be involved in the inspection of code. 
1 laving a manager preseni tends to nut the author on the 
defensive. Also, depending on the person, the inspector ei- 
iher goes on the offensive or withdraws from the process 
entirely. 

• In addition to finding defects (or "issues" ). which helps to 
saw testing and rework time, the inspection process has 
other, more intangible, benefits 

o Increased fceanworik Inspections provide an excellent 
forum for the team to see each others strengths and weak- 
nesses and gain anew respect For each others unique ahi 
lities. By adding the quest inn and answer session to the 
inspection pmrcss. we provided a Ion mi for Hie team to 
discuss issues and creatively solve - the in together 

o Support team education. Including members of the team 
thai would eveimialJ> suppon i the SIT system allowed 
these people to become familial 1 with the system and con- 
fidein thai n ^vould be supportable, 

Testing. The lessons learned from unit and module testing 
include the need for expanded participation in testing and 
the value of tesl scripts, 

• tnit testing. On small project teams H is difficult to coordi- 
nate testing su that someone other than the author bests 



unit. Establishing a process that includes the designer, other 
propamniers, and users helps tremendously towards ensur- 
ing full test case coverage. 

• Module testing. Integration lest scripts are invaluable, 
effort expended to create the scripts for the SIT project was 
significant, especially the first one. However, the reward, 
in terms of time saved and rework, more than justified the 
effort Furthermore, these scripts have been w il to 
the support team for performing regression testing when 
the programs or job streams are modified 

Success Factors. The SIT product was released to production 
in early March 1992. Since thai ume the product has been 
relatively defect-free. In reviewing what has been done, we 
observed some key factors that contributed to our sun 
These success Ea tors run be summarized as following: 

• Strong management support We hat! very strong manage- 
ment support for the inspection and testing process ami die 
imu j commitment involved. This was the most huportanl and 
critical success factor for the implementation erf inspections 
and metrics collection, 

• Team acceptance. The SIT projed team accepted the quality 
concept. We agreed on our quality goals and understood 
how i he inspection and testing processes would help us to 
achieve those goals. 

• FOCUS. The SIT project was selected as I he pilot project to 
implement the inspection process, <. Mir initial focus was on 
code inspection. After the project team felt comfortable 
with doing inspections, other documents such as test 
scripts and lesl plans were also inspected. 
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Clock Design and Measurement Issues 
in Pentium Systems 

Design difficulties in producing a statistically stable 66-MHz Pentium 

system are reviewed. The information is pertinent to many other new, 
high-speed processors as well. A new r more informed approach to 
designing well-timed systems in this performance class is proposed. 
Measurements that support this approach are examined, particularly 
those made with the HP 8133A pulse generator. 

by Michael K. Williams and Andreas M.R. PfafT 



Clock rales in all classes of computational systems, from 
PCs to supercomputers, have keen escalating exponentially 
for years. Computational systems formerly considered sim- 
pler have come to run at speeds thai were previously found 
only in in ore complex and aggressive systems. Before this 
happened, systems at the simpler end or this spectrum (PCs 
and workstations) operated at clock rates ihat don*! present 
very difficult clock distribution and reception problems. 

Recent introductions of new processor types have given PC 
and workstation system designers new chips and chipsets 
that enable system designs thai deliver much higher levels 
61 performance J Most of these devices employ internal 
structures that come directly from die world of mainframes 
and supercomputer's: pipelining, iM bit data buses, on-board 
Moating-poml units, instruction prefetching, and sophisti- 
cated caching schemes. Many of these processors are sum- 
marized in Table 1. These new device families include Intel's 
Pentium processor, Digital's Alpha, the Apple/IBM/Motorola 
IVnverlH \ and others. These ICs have clock rates that range 
from lens lo hundreds of MHz. Some are expected eventually 
to exceed 1 GHz. 





Table 1 




Some New Processor Types and their 


Clock Rates 


Manufacturer 


Processor 


Clock Rate 


Intel 


Pentium 


m and 6b MHz 


Intel 


P54C 


m MHz 


Intel 


486 


G6aiul99Mfl/ 


Apple/IBM/Motorola 


PowerPC 


80 MHz 


Digital Equipment Corp. 


Alpha 


> 100 MHz 


MIPS 


R441M3SC 


130 MHz 



With all of the sophisticated internal structures and taster 
Operating speeds comes a price to be paid by the design 
team. Specifically, successful system design at these speeds 
requires very careful consideration of many mechanisms, 
such as riming and pi 1 1st- fidelity, that are unimportant at 
lower speeds ( Hi to 33 MHz). 



Pulse fidelity, sometimes referred to as signal integrity, is 
thai pari of high-speed digital design thai is concerned with 
managing ihe analog effects that prevent signals from being 
reliably recognized at their destinations. This includes ensur- 
ing that edges arrive al their loads with proper 1 edge speeds 
and proper shapes, and controlling the various types of 
noise (crosstalk, EMI, reflections, ground bounce, etcj that 
can cause unreliable or false triggering. The extent to which 
these issues are important has increased dramatically in PC 
and workstation designs. Wider buses and faster clocks and 
edges (higher wave form spectral content) are the primary 
sources of these problems. The classic discussion of all of 
these analog effects can be found in reference 2. 

Timing, or clock distribution and reception, is the other criti- 
cal facet of design in these faster systems, and is possibly 
the most significant and least well -understood aspect of the 
design. Timing environment design is the process of specify- 
ing how the clock is to be distributed and received through- 
out the system sue it that the state architecture is reliably 
synchronized. Reliable means that synchronization is guar- 
anteed on eveiy cycle of every copy of the design that is 
manufactured, despite the presence of a variety of statistical 
toleraneiug mechanisms (skew, jitter, etc) which reduce the 
precision with which the clock can be delivered. These fob 
prancing mechanisms are described in detail on page 70. 
When reliable synchronization is ensured by sound design 
practices, the design is said lo be statistically stable. 

The question of exactly how to ensure this statistical stability 
is one that each design team must face as they adopt these 
nvw devices into their designs. Success at answering this 
question brings with it higher yields, fewer design I urns, and 
the elimination of extremely subtle timing failures. Methods 
for doing this, while relatively new to designs al the work- 
station and PC level have been commonplace hi the design of 
higher capability systems (mainframes and supercomputers) 
for man} years. A descriptive term for the approach that is 
common to all of these methods is informed design. 
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Fi#. 1. Timing enviromuenl desjjsi process Design-specific and/or 
unrated parametric information tnust be t Into ihe 

engiiu-' L:!^ •. |i-i Eskni ]n.ikin.ii process from theou 

Two results are produced by m informed approach to the 
design of a liming environment the Qibvious one is n specifi- 
cation of a < lo< |< distribution scheme Equally important, 
however, is a detailed knowledge of the tolerance on the 
arrival time of any clock waveform emerging from any out- 
put til any COpJ Ofttttd tH'twuik. nn any cycle of its opeta- 

tion. This knowledge, that is, the tolerance budget, is used 
by the timing verification software to determine if the rest of 
the system is correctly timed. Obviously the quality of this 
determination is a function of the quality of the toleran 
budget Informed design, as it applies hi timing, can be 
viewed as the practice of ensuring that all of the mecha- 
nisms !h:n contribute to the overall tolerancing of the clock 
have been accurately assessed 

Measurement is used to characterize devices and printed 
circuit board processes to see how the, tolerance* This 
deviceh'\H tolerance data is used to compute the overall 
tolerance nn the system clock And this system-level toler- 
II !■■■• is used within the timing verifier to ensure die creation 
of a statistically stable system. Fig, 1 Illustrates where device- 
level parametric data His into the overall derision making 
process, 

In tins article we examine some of the difficulties a designer 
win encounter in specifying, analyzing and verifying a timing 
.-scheme foi a liu'-MHz Pentium system. This hills in the lower 
speed range for the new round of processors. How '.•■■, ei 
ultraiighi rirtiing specifications coupled with the currently 
available implementation technologies (clock buffers, 
printed circuit boards, etc, I make 66-MHz Pentium systems 
among ihe must difficult from a timing environment design 
perspective, We will see. for example, thai the timing wit inn 
the CPU complex t pfocessor, cache controller, and cache 
RAMs) is very sensitive to clock jitter This sensith it>. and 




Pemium of Cache 
Controller Clock 



c700 ps 




Clock 1o any 
Cache SRAM 



Fig. 2. T irrival tim v-ntium 

iig at any 
SRAM must he less thiin Ten ps In every system 

others, make 6*>MHz systems ideal for the informed design 
approach. Furthermore, the issues and methods presented 
are general and extend to other processor types as well 

Pentium Characteristics and Requirements 
An understanding of the difficulties of distributing a clock 
within a Pentium design must begin with an understanding 
of Pentium timing requirements. Our discussion of this as 
pert til the design will be III Miininary form, and the reader is 

referred to ihe Intel documentation** for a more complete 
discussion Of requirements. Also, reference 7 discusses both 
the requirements and (tie various design decisions in much 
deeper detail lhan can be done here. 

A variety Of system configurations are supported by ihe 
Pentium processor The clock rate can be either 30 or 66 
MHz. The system can use either no second-level caching, oi 
it run have 256K-byte or 5 12K-byte cache memories. Systems 
with 256K-bytc caches can operate al either clock rale, while 
5i2K-byte systems are limited iu f»(i Mil/.. A "typical" Pentium 
design is expected to operate al 66 MH/ and have a 256K-byte 
second-level cache, For such systems, there are \z clock 
loads within the * n complex. Depending upon how the 
resl of the system is designed, the total number of clock 
toads will typically be in the range of 15 to 20. although in 
some server systems, this number can range an order of 
magnitude higher. 

The Pentium specification dictates that the arrival times oi 
the clock at the processor mid at the cache controller never 
differ by more than 200 ps. It also states that the difference 
in arrival times between the processor and ;iii\ cache mem- 
ory, and the cache controller and any cache naembjy, can 
never exceed 700 ps (Fig* 2). These fcoleiance ^p^dficifitioiis 
must be met .n n>. 1.6, mid 2,0 volts, in any design there 
will he other I iterance requirements ihat state bow much 
difference in arrival time is permitted between clocks at 
loads within the CPU complex and clocks at loads external 
to it (external loads; These requirements will always be 
directly determined by the design itself However, the over- 
all tolerance budget will usually be driven by the timing 
within the CPU complex. 
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Tolerance Mechanisms in Clock Distribution Networks 



As described in the accompanying article, we are attempting to guard against a 
dumber of statistical tnlerancing mechanisms, such as skew and jitter, that reduce 
the precisian with which a clock signal can be delivered Here we present an 
overview of these mechanisms. 1 For the purpose of considering system timing 
issues, it is useful to separate the system state architecture into a timing environ- 
ment and a computation environment (see Fig V\ The boundary between these 
twn parts at the system is composed of the system state devices, Except for seg- 
ment delay times and nnmmuni cations locality, we don't address the details of the 
computation environment here. The timing environment can he further broken down 
into three sections: the clock or phase gene rat or. the clock distribution network, 
and the memory elements. 

The clock generator supplies the signal whose edges eventually dictate when 
switching occurs throughout the system. The clock generator determines the 
period, pulse width, number of phases, and relatrve phase separation of the clock 
waveform. The primary attributes of the generator to be specified at design time 
are the waveform period and stability or jitter For systems that use a processor 
chip, the period is usually specified by the manufacturer of the processor, Instability 
(jitterl in the waveform emerging from the generator detracts from either perfor- 
mance or reliability Beyond these, there are f reou ent I y secondary issues and 
features that contribute to system testability — freqoency and duty cycle adjust- 
ability, overtone suppression, modes [burst, single-step, fast, and slow), scan-path 
drive and timing, and others. 

The state devices are flip-flops, latches, Dr memory devices of some type. New 
devices with enhanced testability features are appear my more frequently. The 
state devices play an important role in determining the low-levei timing con- 
straints in that their setup, hold, and minimum pulse width requirements must be 
satisfied at mil clock speed. 

The clock distribution network is a network of buffers and interconnects that 
conveys the dock signal to the dock consumers, tt is responsible for fanout ampli- 
fication and is generally tree-strut lured. In simpler systems, all of the fanout can 
occur in a single buffer. In larger systems, thousands of copies of the clock can be 
produced, requiring many levels of buffering (12 to IS levels in some supercom- 
puters]. From a timing perspective, the ideal situation is for -all of the copies of ihe 
clock waveform to emerge from the leaves of the clock distribution network at the 
same moment However, the devices (both b offers and interconnects) that make 




Rg. 1. State architecture mental. Any synch ran nus digital system tan be decomposed into £ 
timing envimnmBU arid a compute environment ihe design issues specific to the timing 
environment are becoming critics! in PC and workstation designs 
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Fig. Z. There are a numbef of metrics of jitter. 
This measurement shows the cycle-to-cyde 
variation ■» the period of a ES-MHz clock. This 
was made using the Amherst Systems 
Assoc iaies Ml ln"r-e i nerval measurement 
software, which analyzes digitized waveform 
data from an HP 54720D oscilloscope for jitter 
in a variety of ways. 
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Receiver Threshold 
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Edge Placement Time 
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Fig. 3. Jitter as it occurs in clock buffers, Is generally the result of noise in ihe power environ- 
•elum currents, (mage currents, etc.] modulating the switching threshold of the buffer 

up the paths through the clock distribution network have a statistically distributed 
delay, These rjfstfrfeutjofls ean be time-mvariani (static) or time-variant Idynamic), 
An example of a statically distributed tolerance is stew in clock buffers. Thfs is 
Ehe variation m delay either from pin to pin m a single package or [ram part to 
pan Interconnects ran also exhibit tolerancing. This is most easily thought of as a 
variation in the propagation rate of several picoseconds per inch (ID to 40 ps/m). 
Interconnect to lerancmg is frequently a source of unanticipated timing failures. 

An example of a dynamically distributed tolerance is jitter. The placement in time 

of a waveform edge that has jitter varies from one cycle to another, It can be 

thought of as having a per tod that changes from one cycle to the next Fig. 2 
a\\a\V2 dn example of Tins variation, Jitter can be added to the clock waveform in 
two places a; the generator or m the buffers. At the generator, jitter can occur 
through either internal noise or dynamic temperature or supply voltage instabilities 
Jitter added in the clock buffers is caused primarily by noise in the power environ- 
ment [return and image currents in power planes sweeping past power and 
yruuud pins, etc ) causing time- varying shifts in the device's switching threshold 
This is illustrated in Fig 3 Mole that jitter (an expansion of the distribution of the 
edge placement) is increased when the noise voltage is increased or the edge rate 

signal arriving at the buffer is decreased The management nf jitter at con- 
si stent and acceptably low levels is perhaps the single greatest challenge for 
designers of systems that incorporate many of the new high-performance proces- 
sors A more in-depth discussion of jitter measurement and management can he 
found in references 1 and 2. 

There are also statistical variations in how two identical parts are used For 
example, one system may run a little warmer than another, another may have a 
little more noise in the power environment, and so on. Some of these tolerances 



1 some are not. As shown in Fig, 4, these device-level disiribu- 
ticjns can tm Stat i ■ a system-levsl distribution on tfie path 

delays in the ciocfc distribution network This sysF telay uistrikrUon 

has a mean value iftat is sometimes called ftie nominal delay, By si 
combining the individual nominal delays along the path one car 
itaJ delay fr 

Whr iinal delays, it is fmponam to keep in mmd Orat there is actually 

n This mer oath in the design is specified 

to be identical when the product is manuJa b products : 

ere will be path-io-path 

a given path m a given machine. The result is that one must design the system in a 
~r that both suitably minimizes these tolerances and consciously considers the 
'olerances will always be nonzero. The design is said to be statistically 
stable when it has ttiis characteristic 

When the tolerances in the system accumulate beyond the value anticipated by 
the designer, the design is said to be statistically unstable, in statistically unstable 
designs, some small fraction of the manufactured systems will experience timing 
failures despite the absence of any physical defects, In these systems, the clock 
can arrive at times other than the designer anticipated, and thrs can mean that 
one or more of the state device timing requirements (setup time, hold time, or 
minimum pulse width I will be violated, 

Violations of any of the device -level timing requirements can result in statistically 
unreliable switching at the state devices This can cause unpredictable deviations 
in normal system-level behavior These faults can be extremely difficult and time- 
consuming to isolate In fact, the failure modes exhibited by systems with internal 
timing problems are easily among the most difficult to diagnose using conventional 
troubleshooting methods. It is frequently necessary to employ an analytic approach 
to find these faults in any sort of efficient manner, These failure modes include, 

• Intermittent or nonrepeating 

• Low frequency of occurrence (minutes through weeks) 

• Migration of the symptom location through the system 

• Hibernation (failures occur as device parameters change slightly with age) 

• Statistical 
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must also take into account correlations \l ■ h :ree- structured circuits, and other 

related mechanisms called tracking effecis 
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Fig. A. A variety of toletancing mecfi 
contribute to the uncertainty in the arrival 
lime of the clock edge at any clock load Gen- 
■ unly one that is ±jv.i . Uitiln- in catalogs 
or data sheets is tha buffer tolarancmg. 
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In general the difficulty of any particular timing > n. iruii- 
ment design can be estiraated torn two facets of the design: 
tlte number of clock loads and the amount of allowable 
clock tolerance, expressed as a fraction of the period. One 
threshold of difficulty occurs at ahout len board-level clock 
loads! and tolerance budgets that are less ihan UM or so of 
the period. For the typical G6-MH/. system we have assumed 
that (he loading [16 to 20 clock loads) ranks it as somewhaT 
difficult The tolerances within the CTl' complex of 200 and 
700 ps represent \M% and 47%, respectively, of the 15-ns 
cycle tii tie. This represents a very challenging timing re- 
quirement Table II summarizes Pentium clock tolerancing 
for various system configurations* 





Table II 
Clock Tolerancing and Loading 
within the Pentium CPU Complex 


Clock 

Speed 
(MHz) 


Cache 

Size 
(bytes) 


Tolerance 

(ps) 


Number of Loads 


m or S6 


None 


N/A 


1 [CPU only) 


66 


m% 


700 


12 (CPU, cache 
control, 10 SRAM) 


60 


512K 


800 


20 ccpu, mm 

cuniroh 18 SRAM) 


60 


256K 


800 


12 (CPU, cache 
control, 10 SRAM) 



Design Example 

In this section, we attempt to Impart some insight as to where 
the tolerance budget comes front We illustrate some of the 
aspects of the design that arc major drivers of this budget. 
Our goal is to show the importance of having complete and 
accurate design information at every step of the process. 
However, the process of completely and precisely evaluating 
each component of that budget is complicated, and is beyond 
the scope of this article. The interested reader is directed to 
References 8 and 9 for a more in -depth discussion of the 
design decisions presented here, 

Before describing the design, we encourage the reader to 
adopt the view that every design decision that pertains to 
clock paths should be made very carefully and considered 
from the perspective of how r that decision impacts the toler- 
ancing of the clock. It is a fact that every physical design 
decision ("buffer selection, transmission line geometry and 
impedance, termination, grounding schemes, etc.) that 
I elates to the clock paths impacts clock tolerancing. 

Preliminary Decisions. Our example design here is a fully 
synchronous 66-MHz system with a 2oGK-byte second-level 
cache. It is based on the use of the Intel 82496 cache con- 
troller and the S24Q1 cache SRAMs. In this discussion, we 

t Most clock buffers have 10 or fewer outputs, When trie number of loads m a design exceeds 
mis level, either mustipie Inads must be clustered oneactt output cr a multi chip solution 15 
required, The former increases the load capacitance range fC^ ;31 C r IP J any QLiput can sae, 
which increases the difference m arrival time between ihe fastest and slowest conditions. 
Tt»a tette* solution using additional devices, increases cost and the length of the c'oci paths, 
which in turn increases the opportunity for tolerancing W occur itt the dock. 




Circles Show Locations of Clock Pins 

Fig. 3. In" ' I his placement for use with their second-level 

cache chipsei. 

make almost no assumptions! t about tin nil rv beyond the 
CPU complex, since the design challenge lies vvilh the 
clocks within the complex. Beyond this, we assume the Intel 
suggested device placement (Pig, 3)« Placement must be 
very carefully considered lor these devices not only from a 
clock-distribution perspective, but alsu from the perspective 
of the times of flight of all of the data, address, and control 
signals. These times are very precisely specified in 1 In- 
Pentium specification. 

As stated earlier, the typical design is expected to have a 
total of 15 to 20 board-level clock loads. To minimize clock 
tolerancing caused by variations in the load capacitance, it 
is desirable to drive the system in a point-to-point fashion. 
This means one clock load per clock buffer pin. We have 
selected a 20-output static clock buffer for this role. It has a 
pin-to-pin tolerance (skew) of 500 ps. 

The interconnect for the design being described here was 
also very carefully considered. It was decided to route all 
clocks in microstrip (typically less tolerancing than stripline 
because of a faster propagation rate). An interactive field 
solver was used to design the microstrip. The resulting 
propagation tale is 14h\4ps/iu 

Predicting Actual Clock Tolerances. A good way to begin is to 
do an inventory Of where 1 he clock loads in the system are 
expected to be placed and get as much information as pos- 
sible ah our what types of loading they will present. Intel 
provides very complete pi-modelsttt for all of the pins on 
the devices within the Pentium CPU complex (also known 
as the "optimized interface group"). These models provide 
minimum, maximum, and typical values. The nnnimum and 

ft We will make reference to worst-case external deck loading when we do foe load/ 
placement inventory 

Mi A pi-modef is a standard ac model of an input pin. consisting of a parallel inductor, a series 
-zapaator and another parallel inductor. 
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Fig. i i he clock nets in our design cai i be viewed as simple 

"terminated transmission lines drivn 

maximum ratings permit an accurate determination of the 
range of distortion delay t that will occur at any pin type. 
Usually, rhe best a designer can hope lor In terms of pub- 
lished parametric pin data is typical input capacitance values. 
This only permits estimation of the typical distortion delay, 
not the range. 

When the clock load inventory is completed, the designer 
will know approximately how far most loads are from rhe 
clock buffer and which buffers are most heavily loaded (iy; 
iral). This information lets the designer estimate how late 
the slowest load typically reaches threshold From this value, 
the other clock paths can be adjusted (e.g., by serpentining) 
to align their typical delays with the slowest one in the sys- 
tem. For this design, the result of the inventory is that the 
largest mean path delay is 1586 ps. The delay ranges for all 
of the other paths in the system are centered on this value. 

Since we used point-to-point dislribution formosttt of tile 
clock paths, the general structure of the dock nets is showE 
in Fig. 1. The general formula for computing the tolerancing 
at this point is: 

u>lerance m , t = skew inT + skew,, x , + jitter, 

Skew^i is the intrinsic skew, that is, the <iela> variation of 
the buffer ipiielo-pin in this case). For OUT buffer, this is 500 
ps. Skew, JX | is I he extrinsic skew, that is, the delay variation 
along the net. Jitter is the peak value, rather than cms i ir 
some other statistical jitter metric. 

Extrinsic skew is not a single mechanism, ll can be broken 
down inio two major components: 

skew ext = ALT |)f i + tol ]lir ^ 

where ALT pf j is the variation in the propagation delay of a 
signal down a loaded transmission line, It takes into account 



t Distortion delay is that component of the delay that a clock edge experiences as ii arrives a* 
the load and enters the die The parametria of the pin, as represented by the pi-mod-. ■ 
a filter ThG more the high -end spectral content of the edge js attenuated, the more the slope 
of the edge ts reduced, adding delav in the amount of time it takes the waveform to climb to 
threshold Wfoet is important with the clock is not absolute delay, but delay variation, so when 
the parameirrcE vary more widely, more variation I tolerance I can occur in the timing at the Din 
Th is ve • i referred to s i rrply as load capacitance vat iai io n 

tr Because of a 2QQ>p5 allowable difference tn arrival time between the processor and the 
cache controller, these two loads are actually clustered at the end of a single clock ml Jh\& 
USSed in much more dera<l in Reference 4 



the range of loads seen at the end of a net. Tol m f g is the man- 
ufacturing tolerance of the interconnect It ranges from about 
1 ps/in to about 50 pain times the length of the interconnect 

ALTpd can be computed from: 



"(f^-fi 7 ^} 



ALTpd = LT; 



where L is the length of the net in inches and T p d is the 
unloaded propagation rate in psin i.] milx and Cj^^ are the 
maximum and nunimum values of load capacitance. To 
pute the difference in arrival times between two clock loads, 
these values will be from different pins. Equivalent values 
for C\ can be models. C is the intrinsic 

itance of the net. 

Following this general format for computing the tolerances, 
we can compute a worstcase diflerence in arrival times of 
the clocks to the cache ciHM n Akr and the cache RAMs. 

700 ps s skew^ + ALT prl + tol nifg + jii ler. 

Plugging in what we computed. 



700 ps 



> 500 + 90 + 60 + jiiier. 



which gives us the constraint on clock jitten 

50 >^s a jiihM 

The ox r erall tolerance budget is summarized in Fig. 5. The 
jitter constraint is very aggressive for PC and workstation 
class computers Normally, this constraint is a Full order 
of magnitude higher. Keeping noise levels low enough to 
meet this constraint will present some unique measurement 
requirements, as we shall see in the next section. 

Incorporating Measurement Information 
We have, thus fan described a number of the more challeng- 
ing issues that must be addressed in producing a 66-MHz 
Pentium design with statist icallv stable timing- We have at- 
tempted to emphasize the importance of employing informed 
design practices. The basic tenel of these practices is that 
important design derisions (e.g., timing veriOcat ion) are 
based upon deliberately and accurately gathered design infor- 
mation. The better this design data is. the better (he design 
decisions that are based upon I. his data. In the case ni tin in ij 



Interconnect 

Manufacturing 

Tolerance 

60 ps 



Buffer Skew 

500 ps 
jPin-1u-Pin> 




Jitter ■-- 50 i 



Total B ml get = 700 ps 

Kifi. 5, ,\i-''i accounting Foi aU of the bolerandng mechanisms we 

nil" "j no i '•; ! i"i i ver, our typical Peritiur* in rtjlercitp 

approximately ■"(> ps of jir i ■ i 
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we are talking about all of the low-level tolerance information 
required tocomput uraietolerateebiM^et 

Asiu>ied on page 7n. \ht- <>nl\ significant compopeHl "Hhr 
tolerance budget that can be found in data sheets is the 
buffer tolerance. All of the other low-level tolerance infor- 
mation must be determined through measurement It cannot 
be generated for a design al one 1 company and shared with 
Others. The luleranre information is determined by Ihr j" 
cific methods and devices employed in a particular design, 
and each design is unique in these regards. 

Perhaps thi> most notable measurement information relates 
lo i he %ery tight jitter allowance. An upper limil of SO ps wilt 
require exploration and experimentation of various design 
alternatives (device placement, bypass filtering, ground 
plane cuts, etc.) to determine their exact effect on jitter. 
Jitter caused by switching noise will be first -order sensitive 
to clock buffer placement And this may involve some mea- 
suivmeut artivii tes that are very new to PC and workstation 
design activities. 

Measurement is usually viewed as a stimulus and response 
process. Stimulus gear includes pulse and function genera- 
tors and waveform synthesizers. Response gear includes 
oscilloscopes, thue-mlerval analyzers, spectrum analyzers, 
and so on. Response is unmieslionahly important when die 
measurement of very low-amplitude jitter (10 to 50 ps) is 
being performed. However, one of the less well-understood 
facets of precision measurement relates to the specification 
of stimulus gear and methods for these measurements. In 
the high-speed PC and workstation designs we're discussing 
here, stimulus issues tenter primarily in two areas: charac- 
hrizatiun activities and applications calling for an alternate, 
adjustable clock source. As w T e shall see, the precision of the 
waveform submitted to a device under lest has a significant 
impact on the quality Of the design data that results from The 
measurement. In this section, we discuss a number of mea- 
surement methods that apply to these two areas. 

Instrumentation Issues. For all of the measurements described 
in this section, the way the measurement is made and the 
quality of the instrumentation employed in the measurement 
are issues of genuine importance. The importance or preci- 
sion cannot be underestimated. Any tolerance on the mea- 
surement tnusi also be included in the final tolerance data. 
That, of course, means thai measurement tolerance directly 
detracts from system performance. 

The very low levels of jitter allowed in the systems we're 
discussing makes the measurements very challenging. For 
example rh< : waveform timiag uncertamty or jitter of ths 
source (pulse generator) must be much less than the jitter of 
the device under test (DLT). Tliere are two reasons for this. 
The first is to avoid corrupting the measurement A good 
rule of thumb is to try to keep stimulus jiiier an < uder of 
magnitude below what you are expecting to measure. In tIklt 
way, the majority of the jitter measured is what occurs 
within the DUT. The second reason for low source jit ter is 
that the tolerance budget establishes an upper bound on the 
amount of jitter permitted on the clocks distributed to the 
loads, and the total jitter on those clock signals includes 




J1+JZ 



Fig. 6, Wlumih- 3etfc£ w:\-i<\ U si is a Bt$tic clock buffer acfci 
jitter mixor. <onib3iiii I .•■•■•I jinu \m-;- , im.-i ■■<umgm 

from the signal source. For tight systems like Pentiums, it, is clear 
thai both die source jitter in n I ih" power environment jinn mh 
I- "|.i to 8 minimum to permit reliable testing and characterization. 

jitter from the signal source. Consider, for example, Fig. 6, 
which shows a clock buffer being driven by an external sig- 
nal source. The buffer can be viewed as a "jitter mixer,* I ha I 
is, the total jitter transmitted to the clock loads is the sum of 
the jitter that the buffer adds because of noise (J2) and the 
jitter on the externally generated waveform I hat drives the 
buffer (Jl). If Jl is significant with respect to J2, it will 
swamp the measurement Furthermore, if Jl + .\z exceeds the 
jitiei limit, the system will not function properly during the 
measurement. Tl\is brings up an interesting point. If you plan 
to make these sorts of measurements and use an external 
signal source, you must account for the jitter of whatever 
signal source you may use in I he tolerance budget 

In our Pentium design, our 50-ps allowance for jitter means 
that if we plan to use a signal source with 15 ps of jitter, we 
should limit jitter in the system to less than 35 ps, A 10-ps 
source will permit the design to work with 40 ps of in-system 
jitter However, to use a source with much more than 15 ps of 
jitter means greater design difficulty in minimizing in-system 
jitter, t and increasing difficulty in interpreting system-level 
jitter measurements because of the difficulty of determining 
how 7 much of the jitter is from the source and how much is 
from the system. 

Substitute Clock Measurements. The must common reason for 
using an external source to drive the clock is to do system- 
level timing margin testing and verification. The fundamental 
question belund these measurements is how T sensitive the 
system is to imperfect device timing, hi other words, the 
sensitivity of the system to variat ions in parameters such as 
frequency, duty cycle, skew7jiiter h or phase separaliontt is 
being determined. 

Fig. 7 illustrates a measurement setup for one type of mar- 
gin testing. Specifically, the setup permits investigating how 
sensitive load number one is to various types of parametric 
tolerancing by eontroliably varying the parameters of the 
waveforms produced by the signal source. For example, by 
advancing the phase of the waveform to load 1 and noting 
where unreliable switching occurs, and then retreating the 
phase of load 1 and again noting where unreliable switching 

t It is probably a useful rule of thumb thai when the stability requirement of the clock in a 
mass-produced computer system exceeds the stability found in precision pulse generator the 
requirement is perhaps too aggressive. 

ft Phase separation is a parameter m systems with m u I fcphase clocks, It is the minimum sepa- 
ration between an edgs in one clock phase and an edge in another 
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Fig. 7. The margin available at a sj in a system can 

exaii : pom a two-channel signal source and 

phase of the channels until unreliable 
switching is « i 

occurs, tile operating limits of the load i clock can be esti- 
mated, f It is common during the course of a design to nerd 
to adjust or ascertain the tolerance al a specific point in the 
system (i.e.. a point tolerance). For example, the dock to a 
particular point in the system niay have to be forced to be 
earlier, or less toleraneed than originally assumed, because 
some aspect of the segment bounded by that state device 
has changed. 

Another critical verification is thai the jitter that actually 
occurs in the final hardware is acceptably low. The designer 
starts with an assumption of what can be achieved. However, 
accurately predicting jitter is difficult, even with "representa 
tive" assessment boards and experiments. Front-end a> 
ment of jitter Ls important, but only an estimate can be pro- 
duced without final hardware. Only the final hardware wiH 
have the actual switching activity, the actual return and image 
currents, and the actual paths and obstacles dial steer liiese 
currents. To verify jilt er, ifs necessary to measure il in a 
variety of 3<»nt inns mid switching conditions. 

One other significant application of an alternate, adjustable 
clock source occurs during debugging, The externa] clock 
ran bypass either the clock source or paths through the clock 
distribution network 1i> pcrniil the investigation of a liming 
problem at the loads. The beueiii of 1 1 us. of course, is that a 
defective source or clock distribution network can be by- 
passed or Tin 1 1 pi ied with a clock with jitter reduced 
to below normal operational levels. 

Characterization Measurements. The verification activities 
described bn the previous section are Intended to determine 
[iow sensitive the system is 10 imperfect timing, Device 
characterization measurements ask the question from the 
Other side-— how imperfect might the timing be? This el. 
Of mea.su nunen is includes fixturecl device measurements. 

For example, phase-locked loop clock buffers are basically 
active signal sources. As such, they have jitter of their own 
(intrinsic jitter), To characterize various facets of this jitter 
1 ' vle-t o-cycle deviation, phase noise, jitter spectrum, smi 
ding lime, susceptibility Go power supply noise, eie . j wit hot 1 1 
corruption from some external effect, it is important to sup- 
ply rhe device with a stable referen. e signal and a clean 
power environment (Fig. 8), Note thai a measurement of the 
intrinsif iiuerofa welhfixturerl phase locked k>Op Hock 
buffer doe* nol i-stah lis h how the device will perform in the 

t Of ecu rsa, th isonl y :,houvs the shok i \ i vi ty f tiff! $ to. However, that m i I 

ihen be guardbanded iq take into account what might happen acrnss a leigsr papulation of 
systems. 
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Loop 



Intrinsic Jitter? 

Peak -to -Peak 

RMS, Spectrum 



Fig. 8. 



signal should be supplied while character- 
i loop. 



system. Instead, it establishes an upper bound on stability. 
The noisier p< ronment and 

less stable reference signals. The spectrum of these distur- 
bances will not likely be consistent in every application, nor 
will it be easily predicted. The behavior of the phase-locked 
loop is affected in a very complex way by the superposition 
of these various external processes. 

Another measurement process that involves the clock buffers 
is the determination of so-called * derating factors."* The pub- 
lished tolerances for clock buffers include not only process 
and rnarmfaei i iations. but also consideration that 

the parts may be operated across a cange of temperatures, 
operating voltages, and loadings. The system designer has 
no control over how buffers vary because of pn >cess varia- 
tions, but does h^ve control over the range of temperature, 
voltage, and loading in the design, and may wish to attempi 
iu remove, thai pan of the buffet tolerance that is attributable 
to these margins on the operating ranges. A series of fixtured 
device measurements made wliile carefully varying some 
environmental variable can yield estimations of how much of 
the published tolerance is attributable to the environmental 
operating range. 

There is also u role for board-Level measurements. As stated 
earlier, the jitter of a dock buffer (phase- locked loop or 
sialic) is affected to a large extern by the level of noise in 
the power aft iranmeni More specifically, it Is determined 
by die noise where the device power and ground pins attach 
to the power and ground planes. This noise is caused by 
image and return currents in those planes. There arc places 
on the board where this noise is significantly higher than 
other places, Furthermore, die gradient of these changes 
can be fairly tight, with quiet points existing millimeters 
from points that cany high image currents All I his means 
thai buffer placement and oriental ion on the hoard have an 
impact oji elock, fitter. It is possible to evaluate approximately 
where the quiet locations are on a "technology board. n Fig. 9 
shows such an experiment. The externa] signal source is 
used to drive a representative collection of switching gal 
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Fig. f>. By examining the powet envir •• ■ giun 

where the doek btrifer is expected i I the quietest power 

and grburtd connector pi s pan be determined 
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It is unlikely thai the gates on the technology hoard will be 
exactly the circuitry that appears in the final design, since 
this sort of activity is most likely performed very early in the 
design process. A grid of (est points in the region where the 
buffer is likely to be placed offers visibility into the power 
and ground planes, and these can be evaluated by a high- 
speed oscilloscope or spectrum analyzer. Once it is known 
where the quiet locations are, the placement and orientation 
of the buffer can be specified. 

HP 81 33 A Pulse Generator. *°< ]1 For many of the measurements 
described in this section, it is critical to use a high-precision 
adjustable signal source, The HP &133A pulse generator 
(Fig. 10) is an excellent Choice for the stimulus instrument 
in these measurements. It is stable, accurate, and precise. 
The rms jitter for this instrument is warranted to be less 
than 5 ps. Both authors have had the opportunity to charac- 
terize a number of these instruments. The result of these 
characterizations is that the distribution is approximately 
Gaussian. Furthermore, for pulse repetition rates below 5(10 
MHz, the rms jitter of the instruments is typically 1.2 to L3 
ps. Rms jitter is equal to one standard deviation of the jitter 
distribution. Worst-case jitter can be taken to be six standard 
deviations. For a Gaussian distribution, this means that 
worst-case jitter is approximately S ps. Applying this to our 
50-ps Pentium tolerance budget, we would have to ensure 
that the system jitter is less than 42 ps to ensure that the 
system functions correctly during testing. This also means 
that most of the jitter of the measurement comes from the 
system and not from the external source. 

When the HP 8133A is configured as a multichannel instru- 
ment (Option 003 is recommended for clock characterization 
and testing activities), the phase delay from one channel to 
i l is j other can be adjusted in I-ps increments from the front 
panel or in 300-fs steps over the HP-IB (IEEE 488, IEC 625). 

If a less stable or precise source is used for these measure- 
ments, the quality of tire results could be compromised. For 



Fig. 10. The HP 8133A 3-«Hz 

pulse generator is an excellent 
Candidate for use as a high- 

' > 1 1 igh -resolution signal 
sourrr tat testing h-muimand 
other high-speed ptfdi i 
designs. 



example, if we assume jitter levels of just a few tens of pico- 
seconds, the system may not even function properly during 
testing and the measurement of any jitter in the system will 
be less meaningful since the majority of the jitter will come 
from Uie external source. 

Summary 

In this article, we have reviewed some of the significant 
challenges that exist in designing a statistically stable dining 
environment Tor a 66-MHz Pentium system. Many of the dif- 
ficulties described easily generalize to most of the other new 
high-speed processors as well. We have advanced the argu- 
ment that a new, more informed approach to designing the 
timing for these more aggressive systems is required. This 
informed design approach requires the determination of 
important design information at the front end of the design 
process so that important subsequent design decisions can 
be made knowledgeahly, with more predictable results. 

We also examined a variety of measurements that support 
this approach. Our tolerance budget for a typical Pentium 
system revealed much more sensitivity to jitter than has 
been common for designs at this level Our discussion cen- 
lered on the measurement of jitter-related design informa- 
tion. In the course of discussing these measurements, we 
also examined the role of stimulus equipment. Specifically, 
we discussed what impact various facets of the performance 
of a high-stability pulse generator would have on the quality 
of the measurement data. For example* the simple decision 
to use a higher-stability pulse generator as an adjustable 
substitute for the clock means that the design can have 
higher levels of intrinsic jitter (i.e.. a simpler design) and 
continue to function during testing. In the course of our dis- 
cussion, we showed how the IIP 8133A pulse generator can 
be employed in designs as aggressively timed as Pentium 
and others. 
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Enterprise Modeling and Simulation: 
Complex Dynamic Behavior of a 
Simple Model of Manufacturing 

Simulating a structurally simple model of a manufacturing enterprise 
revealed complex dynamic behavior Enterprise modeling and simulation 
provided estimates of end-of-life inventory and order delivery performance 
based on interactions of forecast quality, quoted product availability, 
material procurement and safety stock policies, vendor lead times, 
product life cycle, and part commonality An unexpected result was that 
end-of-life inventory can exist even under ideal environmental conditions 
Prospective applications of these methods include estimating the effects 
of incremental improvements, verifying impacts of process changes, and 
generating enterprise behavior information, 

by M. Shah id Mujtabat 



Can we understand the potential impacts of process changes? 
Can we quantify the expected amount of improvements and 
henefits? Can we anticipate the effects of environmental 
changes? Can we predict the effects and side-effects of mak- 
ing changes? And can we do all these before taking action 
and making major resource commitment's? 

We suggest ihat the answer is yes to all these questions, and 
the means is enterprise modeling and simulation. 

The piupose of this paper is to show how enterprise model- 
ing and simulation research activities at IIP Laboratories 
can be applied to predict system behavior and gain insights 
using sound engineering aim scientific principles and tech- 
niques before implementing the new solution at the level of 
the business enterprise* 

In this paper, we first discuss modeling and simulation tech- 
nology in broad terms to provide background and context, 
We then describe one model, the Simple Model, in detail 
and present the insights gained from running simulations on 
that model and analyzing and displaying the results. An un- 
expected insight was that end-of-life inventory existed at the 
end of the product life cycle even though the method for 
computing safety stocks should theoretically have resulted 
in none when customers ordered exactly according to fore- 
cast. Other interesting insights were that high inventory levels 
can occur when actual orders come in too high or too low 
with respect to forecasts, hi other words, forecast quality lias 
a major impact on some of the metrics under consideration. 
We then describe the current state of enterprise modeling 
and simulation, future research directions, and possible ap- 
plication areas, including process reengineering on page 86. 
In the appendixes we include more detailed explanations 
and sufficient technical details of the model to permit the 
results to be duplicated by other researchers. A glossary of 

t Author cart be readied at email address muitBba@tipLrtp.com , 



terms and a summary of the values lor different experiments 
are provided for quick reference on pages 85 and 95. The 
evolution of enterprise modeling and simulation activities ai 
HP Laboratories and lite place of the Simple Model in those 
activities provides a historical context and is described on 
page 90. 

Modeling and Simulation 

Extensive literature exists on the simulation modeling pro- 
cess, for example Chapter 1 of Law and KeltonJ Chapter 1 
of Pritsker,^ Chapter 6 of Mellaney, 3 and Law and Mc Comas. 4 
The general consensus is that the purposes of the simulation 
modeling process are lo define a problem clearly and to de- 
velop a model as a tool to understand and solve that problem. 

"Modeling and simulation have become endeavors central to 
all disciplines pf engineering and science. They are used in 
the analysis of physical systems where I hey help us gain a 
better understanding of the functioning of our physical world. 
They are also important to the design of new engineering 
systems where they enable us to predict the behavior of a 
system before it is actually built, Modeling and simulation 
are the only techniques available that allow us to analyze 
arbitrarily nonlinear systems accurately and under varying 
e xperiment al con di t ions . n5 

"The facility or process of interest is usually called a system, 
and in order to study it scientifically wp often have lo make 
a set of assumptions about how it works, These assumptions, 
which usually take the form of mathematical or logical rela- 
tionships, constitute a model that is used to ay to gain some 
understanding of how the corresponding system behaves. " J 

Thus, a model is a conceptual abstraction of an existing or 
proposed real system that captures the characteristics of 
interest of the system. Modeling is the process of building 
the abstraction (model). 
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"If the relationships that compose the model are simple 
enough, it may be possible to use mathematical methods 
(such as algebra, calculus, or probability theory) to obtain 
exact information on questions of interest; this is called an 
analytic solution. However, most real- world systems are too 
complex to allow realistic models to be evaluated analytically, 
and these models must be studied by means of simulation^ 1 

"Simulation is the use of a model to develop conclusions that 
provide insight on the behavior of any real world elements. 
Computer simulation uses the same concept but rexjuires that 
the model be created through prograxnming on a computer."* 

In general, modeling and simulation are useful when system 
prototyping is too costly or time-consuming, seriously dis- 
ruptive, or simply impossible. They are useful for exploring 
proposed system changes by providing performance esti- 
mates of a proposed system or of an exist ing system under 
some projected set of operating conditions, A simulation 
nrodel or set of models can provide an experimental testbed 
on which to try out new ideas or concepts, since it is 
cheaper to experiment in the laboratory than on the real 
system. 

Our premise is that these techniques applied to enterprise 
processes could help predict the behavior of the organization 
more quantitatively than repeated assertion or the application 
of mental models. 

Enterprise Modeling and Simulation 

We define enterprise modeling as the process of building 
abstractions or models of three primary functional compo- 
nents of an enterprise: manufacturing, marketing, and R&D 
(research and development ) for the purpose of gaining in- 
sight into the interactions belween these functions and the 
interaction of the enterprise with other enterprises. The 
complexity of the enterprise and the large number of people 
who have ownership of different parts makes ii difficult for 
a single individual to grasp a detailed understanding of all 
the components. There is a limit to the level of complexity 
and the means to share and communicate it with others that 
can be carried in ihe head of a single individual. 

Many process changes and decisions are based on implicit 
mental models in the heads of decision makers or advocates. 
Mental models 6 are deeply Ingrained assumptions, general- 
izations, or even pictures or images that influence how we 
understand the world and how we take action. Very often, 
we are not consciously aware of our mental models or the 
effects they have on our behavior^ Generally mental models 
assume that there are a small number of factors in cause and 
effect relationships. The problem with mental models is the 
difficulty of communicating thcm T checking their consistency, 
and combining the mental models of different people. It is 
very difficult to estimate the effects of interacting factors 
and to combine mental models into a larger-scale composite 
model that incorporates the insights, knowledge, and under- 
standing nl many individuals 

One means of merging different viewpoints is the use of 
Hierarchical Process Model ing, 7H which provides an ex- 
plicit, graphical representation of the process with v. hich 
individuals can agree or disagree. Experience in applying 
Hierarchical Process Modeling- 1 to the building of enterprise 
mi if I. is suggests that the result is a repository for knowledge 



of the processes we are studying. During its creation, team 
members develop a common understanding of the dynamics 
of model behavior through interaction with one another and 
with the model. The result is an explicit model that reconciles 
differing points of \tew and a reusable model thai serves as 
a foundation on which to build future models. 

There is an awareness that a model can be used to embody 
knowledge of a system rather than be used as a tool. 10 For 
example, Funke^ states that at the Boeing Company, simu- 
lation has provided "a forum for the collection of process 
operating rules and assumptions in one medium as a basis to 
develop the model" of a process or system. 

Other ongoing works on the application of models to em- 
body knowledge at the enterprise level of manufacturing 
operations include TOVE 1 - and CEVI-OSA. 13 M Pardasani and 
' tircii 1,1 describe the expansion of an infrastructure for creat- 
ing simulation models based on the ISO reference model for 
shop floor production standards to create enterprise models. 

In applying the process of enterprise modeling and simulation 
we need to engage in activities of modeling in the large (with 
"model as knowledge") where the major issues of interest 
are communication and documentation, team coordination, 
modularity and large model development, and mukimodel 
organization, instead of modeling in the small (with "model 
as tool") where the issues of interest are top-down design, 
informal and formal program specifications, simplification 
and elaboration, and validation and verification^' 

In modeling the manufacturing enterprise, the primary area of 
focus is the manufacturing function, which includes, in addi- 
tion to the traditional production and shop floor f mictions, 
the production and material planning, material management, 
and order processing functions. In traditional modeling and 
simulation applied to the manufacturing domain, computer 
simulations have been applied to the production floor or ma- 
chine shop level to study machine utilization and product i< mi 
art! I material flows and buffers. These methods together with 
traditional operations research methods have helped reduce 
inventory on the production floor and nil I mild times to a 
level where these are small compared to the other parts of 
the system. Enterprise modeling and simulation expand the 
scope so that traditional modeling and simulation are com- 
ponents in the enterprise modeling and simulation system. 

Enterprise modeling and simulation indicate the impact, of 
proposed improvement efforts m the enterprise level before 
the changes are made, The "simulation" in enterprise model- 
ing and si mn la) inn is the process of running the model in a 
r-MmpMh-r in understand i In- behaviors "\i-r Bine under differ 
ent operating conditions and circumstances. It will help us 
identify leverage points and indicate where we can expect to 
get the most impact for a given investment or change, ''■' 

According to Senge, e "The real leverage iti most manage- 
ment situations [ies in undi islanding dynamic complexity, 
not detail complex ny" Me suggests that most systems analy- 
ses focus on detail complexity ( that is, a large number of 
variables), not dynamic complexity ( "situations where cause 
and effect are subtle, and where the effects over time of 
interventions w& itdl obvious"}. We suggest dial enterprise 
modeling and simulation help in tinders i a j id 1 1 Lg i lv narnic 
enmjilexity. and in addition provide the framework for 
slowly expanding the detail complexity; 
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Modeling and simulation at the enterprise level are showing 
increasing levels of activity. For example, a recent article in 
Fortune magazine 17 discusses business-oriented economics 
that focuses on what economists call "the firm" and the rest 
of us call "the company* as the unit of analysis. (Traditional 
microeconomics, by contrast, is concerned with markets 
and prices. It looks at the economy or at an industry, but 
rarely peeks inside the individual enterprise-') Fortune cites 
the example of Merck's finance team, which built a com- 
pleted model and subjected it to Monte Carlo simulation 
analysis. 

The Simple Model 

The Simple Model (shown with capital leiiers because of its 
importance in (his paper), was one in a series of models 
developed at HP Laboratories (see page 90). The Simple 
Model was named because of its structural simplicity, but as 
subsequent descriptions will show, it exhibits dynamic be- 
havior that is complex and not intuitively obvious until it is 
explained. Expressed in terms used by Senge, 6 the Simple 
Model Is a tool for understanding dynamic complexity using 
a model with very low detail complexity. 

The Simple Model was commissioned to abstract a real man- 
ufacturing facility with greatly simplified assumptions, such 
as a single prod tin with a one-level bill of materials and a 
trapezoidal order demand pattern. The purpose of the model 
was to explore the relationship between different factors 
and metrics used in manufacturing. Although the mode! can 
generate data on many different metrics, this paper will focus 
on tw^o main metrics: (1) inventory levels and wTite-off at the 
end of the product life cycle and (2) customer satisfaction 
metrics. We will first describe the structure and assumptions 
of the Simple Model and then show the results of raruung 
die model under different conditions. 



Conceptual Description 

Fig. 1 shows conceptually the Simple Mode) of a factory 
producing a product called Adder, t Marketing specifies a 
trapezoidal order forecast profile for customer orders, and 
the number of consignment units (defined as demonstration 
units used in the sales offices ). R&D specifies the Adder 
product structure. Order processing quotes a product avail- 
ability of four weeks. Production determines that the build 
time is two weeks, and shipping slates that transit time for 
sending the product to the customer is one week. We as- 
sume that the production and shipping processes are under 
sufficient control that they do not vary from these constant 
numbers. 

The problem assumes that the values of class A, B. and 
parts in the Adder product make up 50, 30 T and 20 percent, 
respectively, of the product material cost. In valuing the fin- 
ished product, labor cost is small enough to be factored into 
the material cost, and ihe value of the product is the sunt of 
values of its parts. In addition, we assume that the values of 
6-week, ICMveek, and 14- week lead time parts make up 25, 
40, and 35 percent, respectively, of the product cost, that the 
vendors deliver the parts exactly on time, and that there are 
no rejects because of defective parts. 

These characteristics are reflected in Table I, which shows 
the value of each part category. There are a large number of 
unit costs and part quantity combinations that satisfy the 
above constraints. The actual bill of materials used for the 
model is showTi in Table IL 

The length of the longest lead time among the parts is 14 
weeks for parts A, 3, B.3 t and C.3. Allowing a build time of 

f There was a linie bit of whimsy in naming the product The author selected the name from a 
fairytale in when somebody ordered the biggest adder available, expecting it to be an adding 
machine When me box was opened, out popped a snake. Snakes, ot course, was an internal 
HP code name for a class ol workstations. 



82 



December t994 Hewlett -Pack an 1 Journal 



)Copr. 1949-1998 Hewlett-Packard Co. 



Table I 
Simple Model Adder Product Structure 

\b) Product Structure by Part Value 

Pari Value Part Value 

xi tm BA 

■00 B.2 
A3 51750 B.3 SI 050 

(b) Part Value bv Part Class Safety Stock 
Glass Parts in Class Value % Value Safety Stock 

m 

$3000 

$2000 
$10,000 



Part 


Value 


CM 




C2 




C.3 





AJ,A.2.A.3 

C1 T C\2,C3 
Total 
(c) Part Value by Lead Time 



A 
B 
C 



30% 
100% 



4 weeks 
8 weeks 

Hi wi-ek> 



Lead Time 
6 weeks 
10 weeks 
14 weeks 



Pans 

A.l,B,ir .! 

A.3,B.3 t C3 
Total 



Value 
$2500 
$4000 

$3500 
$10,000 



% Value 

25% 

40% 

35% 

100% 



Table II 
Adder Bill of Materials 



Part 

A J 
h2 
A.3 
BJ 

B.2 
BM 
C.l 
t\2 
GJ 



Quantity 
1 
1 

I 
1 
1 
1 
1 
1 
1 



Unit Cost 

$1250 

$2000 

$1750 

$750 

$1200 

$1050 

$500 

$800 

$700 



Value in Product 
* 1:250 

000 

$1750 

$750 
$1200 
$1050 

$500 

$800 

s7uo 



1 \\i > weeks and transit time of one week means that the po- 
nod from the time parts A.3 t B.3 T and C.3 are ordered in the 
manufacturing enterprise to the time that the product U£ 
those parts is received by the customer is 17 weeks, This 
means that the polity of waiting for customer orders before 
we order parts from mir wndnrs will lead loan order-to- 
< 3 el i very time of at best 17 w« ska 

To quote availability of four weeks requires us to order mate- 
rial and plan production before 1 we receive customer orders. 
The best in formal ion we have on current and past customer 
behavior is actual orders, and the best information we have 
on future customer orders is the order forecast. 

t liven that we want quoted availability to be Less than the 
Sum i>f material delivery, production, and product deiiv* 
times, we need tQ plan ahead of time how much to build 
based on older forecasts, This decision an how much to 
build in future weeks is the responsibility of production 



planning, which each week computes the number of units to 
be started in future weeks, 

Forecasts of future customer orders are estimates: customers 
may order more or less than forecasted. In the event that 
customers order less* we should have no problem meeting 
the demand if we build to meet the forecast. However, if 
9 order more, we might run oui of product. To 
allow T for litis contingency production planning must SpN 
that we need lo build a few more units and carry them in a 
stock of finished goods inventory | FGl 1. The amount of ex- 
tra product to be carried is the safety stock, and depends on 
many factors including the average expected order level, the 
expected fluctuations in orders, and how much we want to 
allow for contingencies. A high safety stock level will pro- 
tect us from low forecasts, but requires a greater investment 
in inventory. One way of specifying inventory levels is to use 
a measure related to number of weeks of forecasted de- 
mand, In the case of this model, we assume that production 
planning specifies two weeks of 13-week leading average 
forecast as target FGI safety stock. 

The discussions for FGl safety stock are also applicable for 
raw material There must be enough raw material on hand 
when the time conies to build the product To allow for ex- 
cess demand from the production line because of high cus- 
tomer demand, and for late deliveries by vendors, we need 
to order some extra material. This extra amount is deter- 
mined by material planning and is the target raw parts in- 
ventory (RPI} safety stock. The amount of RPI safety stock 
can be determined in different ways. One way is to use part 
classification. 

In practice, pan classification indicates the relative impor- 
tance of a part and hence the attention it receives. Since class 
A parts are reviewed more frequently, a smaller quantity is 
carried than for the B or G parts. In our model, part class 
determines the amount of material safety slock to be carried 
in weeks, and all parts are reviewed weekly by material 
planning. For A, B, and C parts the fcargel RPI safety stock is 
4, 8, and Mi weeks, respectively^ of the 13 week leading aver- 
age forecast The l^-week leading average forecast and the 
FGl and RPI target safety stocks are discussed in greater 
di -I ail under "Target Safety Stock," below. 

Fig, 2 shov\ 9 Ifce 1 1 apezoidal product order forecast supplied 
by marketing, The demand during each week of a four-week 
month is constant. The demand builds up over three months, 




L+3 U4 L45 L+G 



Months 



Consignment Demand 
Order Demand 



Fig. 2, a<M>t order forecast and 1 pnsignmenl demands ta units. 
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remains constant for L months, and then reduces to zero over 
three months, so the tot a J product, life is L+6 months, hi the 
first month, some units are required for consignment pur- 
poses. The mature monthly demand V is 80 units, and the 
total amount of inventory for consignment is set at L5 weeks 
of projected mature demand, or 30 units. In our experiments 
we used a baseline value of fj months for L. This order fore- 
cast results in a lifetime total of 780 units, or a total fore- 
casted production cost flowthrough (PCFT, see Glossary, 
page 85) of *$7.8 million, exclusive of the 30 consignment 
units. 

Of the many performance metrics for the system during I he 
product life cycle, the three main ones of interest are the end- 
of-life inventory; which needs to lie disposed of or written off, 
the sltipmenl and delivery performance, and the inventory 
during the product life cycle. 

Detailed Description 

The fundamental description of the Simple Model of the 
enterprise and the primary flows and dynamic components 
that interact with it over time are shown in Fig. 3, 

Entities External to the Enterprise. Customers send orders to 
The manufacturing enterprise. In the simulation each order 
for a single unit is sent individually to the manufacturing 
enterprise. The orders go into the backlog of the manufac- 
turing enterprise, and at some point a shipment fulfilling 
each order is delivered to the customer Customers have the 
expectation that the time between ordering and receipt of 
delivery is the quoted availability, but are willing to wait 
indefinitely for orders. 

The manufacturing enterprise sends orders for each part to 
the respective vendor, shown collectively in Fig. 3 as vendors. 
The shipment of physical parts arrives at some time in the 
future determined by the lead time for the part, ideally the 

Forecasts 



Manufacturing 
Enterprise 



Orders 



Orders 




Products 



Fig, 3. Material, order, and information flows of the Simple Model 
simulation. The heavy solid lines represent the flow of physical mate- 
rial, the long-clash lines represent r hi ■ &m bfinforination related to 
individual un.i.T£, and the short -dash line represents the flow of peri- 
odic onte forecasts. The containers represent the accumulation of 
physical material or orders, the pointers represent levels of the quan- 
tities in the containers, and the light solid lines From The contain ■ 9 a 
represent this status information being transmitted tn the planning 
function. The light solid line from the planning function represents a 
control signal flow that regulates the amount of material flowing 
front HP! to W1P and ultimately to FG1. 



time between the issuance of an order and receipt of the 
material (parts) should be the lead lime quoted by the vendor, 
and for all the runs in this paper, this will be the case. 

Functions Internal to the Enterprise but External to Manufacturing. 
Periodically, marketing provides forecasts of customer 
orders in future periods. Each forecast is a list of the quantity 
of products that are estimated to be ordered in subsequent 
periods. In practice, forecasts are updated periodically and 
estimates for the sarin ■ month in the future can vary from 
month lo month. In the model, the forecast is used to com- 
pute the shipment plan, and to compute the KJ-week leading 
average forecast for computing FGJ and RP1 safety stocks. 
R&D (not shown hi Fig. 3) provides a bill of materials 
(ROM) that defines the product structure, Since the BOM 
does not change during the simulation, we do not show the 
R&D function, 

Processes Internal to the Manufacturing Function. This section 
should be read in conjunction widi Figs. I, 2, and 3, 

Onfer processing accepts orders and keeps track or all out- 
standing orders received from customers, and keeps a run- 
ning total of the quantity of products required in the backlog. 
In addition s ii prioritizes the orders by die ranking criterion, 
which in this model happens to be first-in t first-out (FIFO), 
into a ship list. The backlog level is provided to the produc- 
tion planning function. The prioritized list of orders and the 
quantity that needs to be shipped in the current period are 
provided to shipping. 

Shipping fills and ships the orders on the ship list that order 
processing provides. From the point of view oft he manufac- 
turing enterprise, the duration between receipt of customer 
order and delivery of the shipment at the customer site 
should be the time period specified as the quoted availabil- 
ity. Filling an order is attempted no earlier than necessary to 
satisfy the quoted availability taking transit time into ac- 
count. An order is filled and shipped only if at the time of 
the attempi the number of units in FG1 is greater than zero, 
hi other words, shippings objective is to fill outstanding 
orders that need to be filled and not to try to main tain FGI at 
some level. This means that the actual orderto-dehvery time 
for a particular order will depend on wl vet her units are avail- 
able to fill the order at the time the order is due to be 
shipped. It units are not available, the order will have a 
higher priority for being filled in the next period because of 
the FIFO rule used to establish the ship list. 

PratUtcUitn }tltintthi(j computes the current shipment plan 
and build plan. [1 computes the current shipment plan from 
the current order forecasts and current order backlog to 
attempt to satisfy the quoted availability. It then computes 
the current build plan from the shipment plan, build time, 
current FGI, current WIP, and FGI safety stock. 

To come up with a suitable build plan, production planning 
must know about the characteristics of the system it is trying 
to control, that is, it must have a model of the system that it 
uses for doing its computation. An important aspect of t lie 
computation is to take into account the number of units 
already in process rather than relying only on the number of 
units of product required. Such a model is generally a mathe- 
matical or analytical model, and the formulation is described 
in Appendix L The build plan for the current period is used 
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Glossary of Terms and Abbreviations 

Abbreviations 

A/F -: „5i? precast ratio. This is the ratio of tfceactuat orders received to the 
Norma l!y expressed as a percentage. Aft greater than 100% 
&s that actual orders car s, forecasts 

low or oer a 
Sower than forecast m s low 

BOM, 1 - of materials arrrbly 

ami their respective qua 
■ Single-level BOM The components are raw materials fabricated or manufactureo 

elsewhere (i e.. purchased parts} 
• Multiple-level BOM. Hie components are other assemblies and purchased parts 

EOL End of Jife (end of product life cycle! 

FGJ. Crushed goods inventory, 

RPI. Raw pans inventory. Raw material in stores wafting to be processed 

WIP. Work m process Raw materia! on the production line being assembled into 
the final product 

PCFT. Production costflowthrough. Dollar value of production passing through the 
manufacturing enterprise. Because of the assumptions underlying the Simple 
Model, in this paper FCFT is synonymous with shipments from the manufacturing 
enterprise. 

Terms 

Backlog. Products ordered by customers but not yet shipped. 

Build Time. The time required for completion of the product when all the parts 

are available. 

Committed Inventory. The total inventory to which the manufacturing enterprise 
is currently committed, It is the sum of the on-order material and the on-hand 

inventory. 

Consignment Inventory. Inventory in the sales offices and for demonstration 
purposes. 

End-of-Ufe Inventory. The amount of inventory left over at the end of the product 
life cycSe. that is, when no more orders are bscklogged or outstanding for the 
product EOL inventory includes leftover unused RPL unshipped units m FGL and 
consignment inventory. In general material and products left over at the end of 
the product life cycle are not useful for anything else and must be written off. 

Forecast Quality. Qualitative description of the amount of deviation of actual 
customer orders from forecasted orders The ratio A/F described above is one way 



to quantify forecast quality forecast quality is best for A/F - 1 00%, and gets 
worse as A/F moves away from 100%, 

Lead Time. " * rne between placemem of an order to the vendors 
ofth6 

On-Hand Inventory . - physic iwnedoy the enterprise 

ttesumofRPl.vV 

On-Order Inventory. Same -? 

On-Order Material. Tre total amount of matenaf for which Of 

opens eases eacr 

new order is tssued and sent to the vendor, and decreases each time a shipment 

of parts rs received from the vendor 

On-Time Delivery. Measures whether the order is delivered to the customer 

within the quoted availability. When described in units or dollars, it represents the 
units or dollar value of the deliveries that are delivered within the quoted delivery 
time. When described as a percentage it represents the percentage of on-time 
deliveries with respect to the total deliveries. 

On-Time Shipments. Products that were shipped to customers within the quoted 

availability minus the transft time, that is. those stopped to arrive in trme to satisfy 
the quoted availability. 

Order Backlog, The total amount of outstanding orders from customers that 

have not yet been shipped, it increases each time a new order is received from 
customers, and decreases each time en order is shipped to customers. 

Order-to-Delivery Time. The time period from otder issue to order delivery at 
the customer site 

Order-to-Ship Time. Time period from order receipt to order shipment at the 
manufacturing enterprise. 

Orders Delivered. Orders that have been delivered to customers 

Orders Shipped. Orders thai have beeo shipped to customers. 

Product Life Cycle. The general shape of the increase, leveling off, and decrease 

in order volume for the product. We assume here it is trapezoidal. 

S and S Plus S is a language and interactive programming environment for data 
analysis and graphics developed at AT&T Bell Laboratories. S-Plus is a product 
version of S that is sold and supported by Statistical Sciences, Inc. 



to i rigger the start of the appropriate number of units In the 
current period 

Material planning uses the BOM to generate a material con- 
sumption plan for each part that can support the build plan, 
[I ilnn uses the materia] consumption plan, on-order material. 
RPI. RPJ safety stock, and part Lead times £o determine the 
material ordering plan, that is. how much of each part to 
order in the current and future weeks. Details ofihe compii- 
ni! ion of the consumption and ordering plans are given in 
Appendix I 

Material ordering sends orders for the appropriate amount 
of each pan in the current week to the vendors. As each 
order Ls jsent, the on-order material for thai pan increases, 

Ratr material store* (not shown in the figures) receives and 
Stores mi 'tuning material in RPI and provides material to 
production when requested. As ii receives deliveries from 



vendors, it; sends information about the shipment to on-order 
material wtiich is reduced by the amount of the shipment 
received. 

Production receives a build plan and requests as much 
material as required from raw material stores to build the 
number of units required. Only complete sets of parts are 
drawn from stores, that is, if one or more parts are not avail- 
able in sufficient quantities, all pails are drawn partially. For 
example, if the build plan calls for 10 units to be built, and 
there are only 5 units of part A.3 anci more than 10 units 
each of the other parts in RPI, only 6 units of of each part 
will be drawn and sen! to WIP. and unly 5 units can be 
started, The objective of raw material stores is to fill re- 
questfi for material if possible, and not to maintain RPI at 
any particular level. The mathematical derivation of the 
number of units actually stalled subject io the available 
material is given in Appendix I. 
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Enterprise Modeling and Simulation Applications in Re engineering 



Process reengineering as defined by Hammer and Champy in their book, Reengineer- 
ing the Corporation? is "trie fundamental rethinking and radical redestgn of business 
precedes tn achieve rtramatic rmpmvemenis in critical, contemporary measures of 
performance, such as cast, quality, service, and speed." It is being appJied at an 
increasing rate by three kinds of companies: those in deep trouble, those not yet m 
trouble but whose management has the foresight to see trouble coming, and those 
in peak condition wrth no discernible difficulties whose management is ambitious 
and aggressive These three categories covers large number af companies Thy 
impact rs on processes with throughputs measured in the billions of dollars. 

fleengineering is pervasive, controversial, and disruptive, anrf has different 
interpretations. CSC Index, whose chairman is Champy, 1 states thai, even though 
they pioneered the practice of reengineering. they are startled by how widespread 
the phenomenon has become Their survey results 2 based on 497 large companies 
in the U.S.A. and another 124 in Europe show that 69% of the U.S, companies and 
75% of European companies are already reengineering (average completed or 
active initiatives in excess of 3). More than half of the rest were planning to 
launch an initiative over the next 12 months or were discussing one, 

Hammer and Champy 3 mention three kinds of techniques that reengineering teams 
can use to help them get ideas flowing: bofdly apply one or more principles of re- 
engineering, search out and destroy assumptions, and go looking for opportunities 
for the creative application of technoingy 

A sampling of the literature reveals that redesign is influenced by the past 
experience of the reengineering team and the recommendations of reengineering 
consultants. Ultimately, many redesign decisions are made on speculation based 
on implicit mental models, convincing arguments by vocal proponents for change, 
sheer optimism, blind faith, or desperation 

A major concern is the uncertainty of predicting outcomes, Radical redesign and new 
ideas bring the possibility of boundless gain or tremendous loss. While assumptions 
are being searched out and destroyed ruthlessly, it should not be forgotten that 
some assumptions are rooted in scientific principles which cannot be ignored with 
impunity no matter how highly enthusiastic or motivated the reengineering team. 

Enterprise Modeling and Simulation 

Some areas suggested by Hammer and Champy/ 1 lor reengineering the corporation 
include product development from concept to prototype, sales from prospect to 
order, order fulfillment from order to payment and service from inquiry to resolution. 

The Simple Model described in the accompanying article is a start towards address- 
ing order fulfillment Modeling and simulating the other processes on the list require 
different kinds of knowledge acquisition. For example, product development requires 



more knowledge about the R&D function, sales requires more knowledge about tfee 
marketing function, and service has not been considered in the current model, where 
the focus is on manufacturing 

The following paragraphs describe areas where enterprise modeling and Simula 
lion and the enterprise modeling and simulation system may provide value in the 
reengineering effort 

Identifying Processes 

Hammer and Champy* suggest that once processes are identified and mapped, 
deciding which ones require reengineering and the order in which they should be 
addressed is not a trivial part of the reengineering effort, Typically there are three 
criteria for making the selection dysfunction, importance, and feasibility. 

Enterprise modeling and simulation provide one way of gaining insight in these 
areas by generating performance metrics with and without the change under differ- 
ent circumstances, for example, the Simple Model showed the importance of differ- 
ent controllable and uncontrollable factors to the different system performance 
metnes such as EOL inventory and order-to-del ivory cycle times, 

After selecting a process for reengineering, an understanding of the current process 
is crucial it is necessary to know what the ejus ting process does, how well lur 
poorly) it performs, and the critical issues governing its performance from a high- 
level view, This understanding is the prerequisite to redesign The key is under- 
standing the process rather than completely analyzing it in agonizing detail 

Enterprrse modeling and simulation offer at least two ways of obtaining this under- 
standing and possibly showing the cause of the dysfunction First, the very act of 
building a consensus model that different people can agree with sheds light on 
what might not be working. Second, simulating the model will confirm or reject 
the validity of what is suspected. For example, after building the Simple Model, it 
was possible to test it in a large number of possible operating conditions to provide 
understanding of the cause and effect relationships, The first major insight from 
simulating the model was that what appeared to be a reasonable way of compulmy 
safety stock that would go to zero as demand went down actually gave rise to 
end-of-life inventory even though the demand was forecasted accurately. Enter- 
prise modeling and simulation provide a way of gauging the relative impact or 
different process changes as a step towards selecting the appropriate suhprocess 
to reengineer, and of quantifying the amount of prospective improvement 

Enterprise modelmg and simulation can show the prospective impact of infeasible 
changes. In simulating the proposed reengineering changes, even if they are 
mfeasabJe, the results will indicate if there ts any promise in further consideration 
of a particular direction. For example, it is clearly not feasible to have zero build 



The required material is drawn from RPI and goes into W1P 
where it remains for the duration of the build period. After 
that, the completed units go into FGI, 

Target Safety Stock. Inventory is the amount of physical 
material, and ideally the enterprise would like to maintain it 
at or close to zero in RPI and FGI, and only carry il in WIP 
when raw material is being converted into fmal product. In 
practice- to reduce the effects on production of late vendor 
deliveries and customer orders coming in higher than fore- 
casts, safety stock needs to kept. In die Simple Model where 
vendor delivery lime uncertainly is not an issue, to allow for 
the contingency lhat customer orders W8§ come in higher 
than forecast, production planning targets the FGI safety 
stock to be two weeks of 13- week leading average forecast, 
and material planning targets RPI safety stock for each part 
to lie the quantity of that part required for the production of 
the number of weeks specified in Table 1(b) of the 18- week 
leading average forecast. 



The 13- week leading average forecast at the end of a particu- 
lar week in the future is the sum of the order forecasts over 
the 13 weeks immediately following the particular week 
divided by 13. This average anticipates trends 13 weeks (one 
calendar quarter J into the future, increasing as order fore- 
casts increase, and decreasing as order forecasts decrease. 
In particular, I he 13-week average forecast is zero at the end 
of the product life cycle, which means that any target salVu 
Stock expressed in weeks of 13-week leading average will aim 
for a zero target safety stock level at die end of the life cycle. 

Having specified target safety stock in preparation for de- 
mands higher than forecasted, whai is the impact if custom- 
ers order exactly according to forecast? The expectation is 
that actual FGI should be equal to targeted FGI safety stock- 
level, and act ual RPI for each part should be equal to targeted 
RPI safety stock level for that pan. 
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time for products and zero transportation times for shipments in the real * 
but setting shose values Id mm in me model indicates tne theoreticai maximum 
■ ts of these a the magnitude off the results provides a data point 

for decisions on how mutfi investmt vmq these two times t: 

instead of on other opr 

more r DYS^ tf the changes, enterprise 

Be expected to take effect. Inertia is a j 

most systems, reflected in trie time taken to respcr as or 

chan : res are predictable in th fs i - -be- 

havior for organ tTationa the enterprise is teas predictable 

>e it is not understood as we]] £ >di!ing and simulation help to 

increase me predictability of system behavior given that we know something 
about the systems structure and the behavior of its components White immediate 
improvement for reengineering 15 the desired goal, enterprise modeling and simu- 
lation can show the length and causes of delays in obtaining the desrred result 

Exposing and Challenging Assumptions 

Hammer and Champy suggest that we question assumptions £ Enterprise model- 
ing and Simula! ion require assumptions m be stated explicitly during the mode! 
building process to reconcile differences m points of views. Challenges and dis- 
agreements on the validity are with respect to clearly stated assumptions ra&Sf 
than differences in opinions resulting from differences in mental models of differ- 
ent individuals. For example, the production planning and material procurement 
processes used in the Simple Model are expressed mathematically in Appendix I 
If these are accepted as rational methods of planning, then there is no question or 
debate on the values of the outputs for a given set of inputs If processes expressed 
mathematically are not acceptable as rational methods of planning and an alter- 
native method is proposed, then that alternative method can certainly be tried, 
and the results compared with the previous method. The debate and challenge for 
improvement becomes one of improving the logic of planning rather than one 
revolving around the meaning of words and labels or one on how the model 
should behave based on pas! experience or speculation 

The approach advocated by Hammer and Champy suggests that changes be made 
by understanding the problem and devising the solution This is central to model- 
ing and simulation in addressing problems rn the realm of the enterprise, Enter- 
prise modeling and simulation offer a way of testing and verifying that given the 
current knowledge, the results of the simulation do not exhibit any obvious flaws 
before the process is implemented. 

Role of Technology 

Hammer and Champy devote a whole chapter to discussing the essential enabling 
role of information technology, and assert that modern state-of-the-art information 
technology is parr of any reengireermu, effort. They caution that the misuse of 



ogy can block reengineering altogether by reinforcing old ways of r 
and old behavior patterns, and that equating technology with automation does not 
result in reengine- 

We suggest mat the application of enterprise modeling and simulation is a creative 

zerstood technology to the proc e : nterpn se 

The techmlogy of modeling and simulation has been applied to fields such as 

-signofphv 310 

be ap, .rocesses of me e sbles 

the c * *■- the tremendous increase in 

computational pov. 1 e to suggest another rule along 

ies of the rules described in reference 1 

0/d/?u/e Decisions regarding process changes are based on mental models 
data 

Disruptive Technology: Enterprise moo'elmg and simui;' 
New Rule: Decrsions regarding process changes are based both on historical 
data and analysis of computer simulated behavior of explicit models with 
explicit assumptions thai snow the prospective consequences of different 
'■nns under a large number of operating circumstances 

Conclusion 

Beengrneenng is a philosophy of renewal and rapid, discontinuous, and drastic 
change in the way corporate enterprises do their work, which bnngs with it uncer- 
tainty and fear of the unknown future It is disruptive and controversial, and there 
is as yet no agreement that successes outnumber failures. During the implementa- 
tion, "People focus on the pain of the present and the joy of the past. They forget 
about the pain of the past and the joy of the present " 7 However, given that it is 
occurring on such a wide scale, we suggest that application of enterprise model- 
ing and simulation can increase the chances for success by (1 ) quantifying the 
potential benefits of the ^engineered process in an explicit, defensible way, (2) 
illustrating the transition between the pain of the present and the joy of the future, 
and (3) showing the possible outcomes of current actions, thereby making the 
future more predictable and less surprising to those most affected by it 
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Simple Model Simulation 

Th e S i 1 1 1 \ j I c Mode] 1 1 esc ri bed above represents a simple pro- 
cess design for a rnaniifacturing facility that issuhjecT to 
Simulation. < m the surface, ihe design appears to be reason- 
able and adequate, and in fan is based on representative 
data and characteristics of the process. However, simula- 
tions will show some unexpected behavior, hs well as the 
envelope of the possible behaviors 

Tlie Simple Model was executed on an evolving system called 
the EMS system, which consists of two parts: Ihe simulation 
engine pai-t ami the data analysis and diaplav pari. The simu- 
lation engine has continued to develop with each model that 
we have studied It captures and abstracts processes m the 
enterprise. The simulation engine is an object-oriented, en- 
hanced disc reie event simulation software system. 

The initial Irr^Iernentation of the simulation engine pan of 
the KYIS system was the Manufacturing Knlerpnse Simula- 
tor otf dir Ti Explorer Il.'Tlie current implementation runs 



on HP 9000 Series 700 workstations at the Manufacturing 
Systems Technology Department of HP Laboratories, The 

implementation language is the Common Lisp Object Sys- 
tem (CLOS). ,H The simulation engine has been implemented 
in CLOS provided by three ditierem vendors Franz. Inc., 1 " 
Lucid, toe..- and Harlem 1 in. Lid.- 1 Models subsequent to' the 
Simple Modi'l (see page 00) were latO' enough to stress the 
limits of all three implementations. Graphical output was 
produced using S-Plus. Further details of 1 he history and 
development of the EMS system are given Ln reference 9. The 
initial version of the Simple Model was implemented within 
a week based on the full order-to-ship model 22 1 see page 
90). It then took successive refinement and a tremendous 
•1 1 "I time to ;umlyze the results. 

For the reader fantiliar with discrete even! simulation. details 
of the Birnilarities and differences in concept between this 
implementation and conventional discrete event simulation 
an- discussed in reference 9. [n general, orders and shipments 
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Fig. 4. Nomina I ease Inventory components as functions of time. The i xpeito ;:iions are shown in Fig, I , 



arc modeled as the entities of discrete event simulation. 
Backlog, on-ordcr material, RP1, WIP. and FOI are modeled 
as queues. Customers and vendors are modeled as s* mrec- 
sink combinations of <>r<U is and material and vice versa 
Production is modeled as an activity. 

The production and material planning functions, which are 
essentially informal inn processing and decision making ltm< - 
lions, are implenu nied as mathematical models einhedde<l in 
the simulation. The information generated by these planning 
functions determines when and how many mats of product to 
start hull cling and how many units of material to order Thus, 
we can ihink of (he Simple Model as an analytical mathemat- 
ical model embedded in a discrete event simulation model. 
The analytical model | formulation given in Appendix I ) dic- 
tates how the simulation model should behave in die same 
way as the planning functions dictate how operations should 
be handled in reality. The simulation model is the reflection 
of physical reality and reflects the behavior of the physical 
system that is told what to do. 

There are two aspects of uncertainty hias and variance 
Most simulation models focus on variance and assume lias 
(offset) to be zero. While the EMS system supports the abil- 
ity to simulate the model under stochastic conditions, in the 
runs described in this paper, variance is always zero and the 
emphasis of the analysis is on the situation in which bias 
can be nonzero* 

Each run represents one combination of inputs and parame- 
ters of the system, and the traditional statistical analysis of 
means and confidence levels is not directly applicable for 
the analysis of these runs, While process variances are im- 
portant considerations in a system, the motivation of this 
work was to identify the first -order effects of the various 
factors, considering the variances as second-order effects. 

Details of the timing of the event sequence are shown in 
Appendix II. 



Experimental Results 

Experiment 0: The Nominal Case 

The nominal case experiment assumes ideal conditions for 
testing the model The ptupose is to establish model baseline 
behavior and offer face validation by verifying that results 
are consistent with intuition and the observed behavior of 
the real system. Initial conditions foi committed inventory 
and backlog are set to zero, A warm up period of five months 
(20 weeks) allows tnaierial io be ordered and received be- 
fore rust* imer orders arrive on week 2L The last customer 
orders arrive on week 68. Order forecasts are c< insistent 
with the trapezoidal profile already defined, and while they 
are generated weekly, they do not change from week to 
week. Week 21 corresponds to I lie first week of month 1, 
and week 68 corresponds to the last week of month Lh-6 in 
Fig. 2. Production begins during w r eek 19 to ensure units in 
FGI at the end of w^eek 2L The computation of FGI and RP1 
safely stock levels is assumed to apply only for weeks after 
week 20, Up to and including week 20, the required safety 
stock level is set toll 

Time Response of On Hand Inventory and On-Grder Material. 
Fig. 4 shows inventory levels measured in dollar terms over 
time. The two bottom regions show fite onorder material 
and on-hand inventory for consignment units. There is a 
gradual buildup of on -order material, which is rapidly trans- 
formed into on-hand inventory over four w T eeks P followed by 
a flattening out (since the consignment units are never 
shipped). The middle region shows on-hand inventory for 
trade or shippahle units, which is the sum of RP1. WIP and 
FGL The upper region shows die on-order material commit- 
ment for trade units. The top surface of the graph show T s 
how total material commitment changes over time. 

Inventory Investment Cotunufted inventory at the end of week 
20, before the first customer order arrives, is approximately 
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$3*6 million. If orders to vendors cannot be cancelled, this 
$3.5 million commitment must be disposed of [f we decide to 
cancel the product before the first customej ( >rder arm 

During the marine part of the life cycle of the product, the 
i >ii hand inventory is approximately $23 million and the 
total committed inventory is approximately $4*7 million. To 
support shipment levels of $200,000 a week requires $47 
million of committed inventory £23.5 weeks of steady-state 
PC* FT) and $2.32 million of on-hand inventory (\l.& weeks of 
ste;id\ -state PCFT). both of which include $300,000 of con- 
signment units (1.5 weeks of steady-slate PCFT). Details of 
tin' computations verifying these numbers in the simulation 
are given in Appendix fV-2, The maximum inventory exposure 
over the life cycle is $4.7 million. 

The EOL consignment Inventory of $300,000 reftects iln 

amount of potential wnte-ntT because we < ltd nut dispose of 
the consignment units. The EOL non consignment inventory 
for trade units is reflected in the tail of the graph, and its 



value is approximately $64,000, If the material cannot be 
consumed any other way there is an EOL write-off of 
S(il.uiH) ul ru>ni onsignmenl inventor} and $800,000 ot con 
uuuTii inventory for a PCFT of $7.8 million under ideal 
Conditions of perfect forecast i|itality and on-time vendor 
delivery 

Time Response of Other Metrics, f iu g shows other time sei ies 
metrics in comparison to orders received The shipment 
profile (Fig. 5a) is identical to the order profile but shifted in 
lime by three weeks. This is because the lout-week availahil- 
ii : ii 14 1 1 me-week transit time require three weeks of order- 
lo-ship time fur on-time delivery. 

Steady-state backlog Fig, 5b) is $600,000, Or three weeks of 
orders- Again, this is because the four-week availability and 
one-week transit time result in orders staying in backlog for 
three weeks, that is, the current backlog is the sunt of the 
last three weeks of orders. 
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Enterprise Modeling and Simulation Research at HP Laboratories 



Our work at HP Laboratories an enterprise modeling and simulation is an outgrowth 
Df the factory modeling project, which began m early 1987 While we were work- 
ing in the area of robotic automation for manufacturing, we began to appreciate 
the complexity of the geographically distributed, nuiltientity marketing, manufac- 
turing, and distribution operations necessary for HP to remain competitive We 
also realized that there were very tew tools available to help understand, design, 
and operate these compfex systems. 

Having been involved in product design with the evolving use of CAD and CAE 
tools, we thought that there was an opportunity of potentially tremendous magni- 
tude for applying similar technologies to the design and operation of the factory 
and business systems used to market, manufacture, and distribute products. In an 
effort to capitalize on this opportunity, we began identifying the primary elements 
of a singfe factory and building our preliminary order-to-ship model that spanned 
all major activity from the receipt of an order to its shipment 

Preliminary Order-to -Ship Model 

This early model was a vehicle to show the feasibility of applying simulation at a 
scope larger than a production line, where simulation was beginning to be applied. 
Developed and proposed for discussion purposes, it was a model to analyze why the 
order-to-shrp time for some products stretched to weeks when the application of 
modern manufacturing techniques had reduced the build time to a matter of hours 
More details on the reasons behind this work are given in references 1 and 2 

Full Order-to Ship Model 

By late 1988 the preliminary model was ready for testing in a real-world context, 
Data and operational information were provided by a real manufacturing division 
to help enhance our early model This process helped to validate the preliminary 
order-to-ship model and led to the development of the full order-to-ship model. 3 
The primary factors considered were order forecast quality production capacity 
constraints, supplier lead times, and order filling policies The primary metrics or 
interest were order lateness, backlog, and inventory, The model included three 



distribution centers, one manufacturing entity, and a centralized sales and order 

entry system, It was configured for one-tevel bills of materials [B0M|, multiline 
orders, and long life cycle products. 

The results of the analysis done with the full order-to-ship model were encouraging; 
they showed things that were consistent WJlh real-world experiences [e.g., high 
forecasts led to hjgh inventory and low backlog]. The results also provided a view 
of greater potential by helping to identify areas for future improvement [e.g.. the 
dominant cause of product shortages is long lead time parts coupled with poor 
forecasts rather than the build time) 

While the results of this model were modest, the building and running of this model 
enabled us to explore some important technologies I i.e.. Hierarchical Process 
Modeling for knowledge acquisition, a discrete event simulation language, SLAM II. 4 
and a know! edge -based environment. Knowledge Craft, for system representation 
and building Simulations). Qur efforts led to generalized enterprise- level modeling 
elements and an object-one rued simulator, We also identified some new obstacles 
fe.g . managing large amounts of simulation data, extracting inrnrmatranl to be 
overcome in attaining our goals. More details are given in reference 1 

For about a year, no further model development was done, but rather, much effort 
was put into consofdating what we had learned about the modeling and simulation 
issues. This effort led to the complete overhaul of our modeling and simulation 
code while migrating it to the Common Lisp Object System on HP workstations 
The power and speed of cui system took a quantum leap forward 

Simple Model 

With our improved system ready, we were presented with another real-world 
opportunity to apply our techniques. The Simple Model was proposed as a means 
Lif pulling together the main activities, processes and circumstances involved in a 
manufacturing enterprise. The primary purpose was to understand end-of-hte 
(ECU inventory and order delivery performance issues. The combined impacts of 
several environmental factors and operational policies were considered in the 



Fig, 5e shows an initial spike in WIP preceding the start of 
orders by two weeks. This happens because the number of 
units stalled during week 19 is not only what is to be shipped 
two weeks later, but also the quantity dial must he in FGI 
(approximately two weeks of orders) at the end of week 21. 
The WIP levels taper off downwards starting in week 44 
towards the latter part of the life cycle because as the de- 
sired FGI safety stock level decreases, less production is 
required than is shipped because some units shipped from 
F< tI do not have to be replenished. 

Fig. ~»d shows material orders. The three large spikes in 
material orders are caused by different lead limes for pans 
to fill the targeted RPI safety stock at the beginning of the 
eyrie. Kaeh of the tiuee small spikes corresponds lo die 
different lead lime parts for the initial WIP spike. Once the 
initial spikes are past, the material ordering volume is ap- 
proximately the same height -is the customer orders, except 
that it is slutted earlier in Time, showing that once the sys- 
tem has reached mature demand, material inflow in the form 
of materia] ordered is balanced by the material outflow in 
the form of shipments. Material ordering starts ramping down 
beginning in week 28 just as the orders 3 each the maximum 
demand for this particular set of cireumsiaiu es. 

Fig. Be shows RPI as a function of time. Notice that the 
vertical scale is different from the other graphs. The RPI 
level is 7.6 weeks of PCFT during the mature demand period 
and st aits ramping down in week 44, Fig. 5f shows FGI as a 



function of time. The FGI safety stock during the mature 
demand week is tw T o weeks of PCFT, which is the same 
as two weeks of steady-state orders. The FGI level stalls 
ramping down in week 44. 

Inventory Results. The results establish the baseline behavior 
of a system designed to take contingencies into account 
when those contingencies do not occur. Appendix IV pro- 
vides further details for computing some of these results on 
a theoretical or common sense basis. Some interesting ob- 
servations can be made. First, EOL inventory and write-off 
1 '\isr even though customers ordered exactly according to 
forecast mid we expect safety stock to go to zero. Second, 
the level of inventory required to support this level of busi- 
ness can be (ruanufied Third, long lead lime pails make up a 
greater percentage of the value of parts on order than their 
percentage in the product structure. 

EOL inventory is important for short rife cycle products 
because die inventory cannot he used for anything else and 
must be written off. hi this case it is a result of the way of 
computing safety stock. It occurs if in the eai l> part of the life 
cycle too much material is ordered because of high targeted 
FGI and RPI. For short life cycle products it can be a signifi- 
cant percentage of PCFT. EOL inventory is less of an issue 
for long life cycle products because the leftover inventory is 
generally a smaller percentage of total Pi Kf and excess 
inventory in early periods can be used at a later time. 
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analysis. The model, leveraging our earlier work, dealt with a one-level BOM, one 
f aciory. one product and sufrsequemfy a f 3mH> of successive products wtih cornmon 
pans and ovettappmg fife cycles. 

a lysis provided some inu ch as certain materia! procure- 

ment : xk pol icm result in EOt frrventorv even for perfect artier fore- 

casts, and with low forecasts, increasing material lead times and planning frequency 

"eased EOL inventory More important webegan 10 realize that we 
were n could reaBy have a positive impact for HP In fact the 

busmen toiherjgv- *-e planning' calendar moc- 

- 
connecting tne output to S-Wus 5 - 6 (or data analysis and the creation of a L 
interface to display output 

Planning Calendar Model 

The purpose of the planning calendar model 7 ^ was to determine the effects Of 

planning cycle times on inventory levels. It required extension of the Simple 

Model to include production planning and materiel planning cycle times It approx- 
imated a uvc- level BOM and multiple assembly sites using a one-level BOM at 
one site It used historical forecasts and orders, The pnmary factors were forecast 
quality, the length of the pfannmn cycle, and the maximum lead tpmes for parts 
The primary metrics of interest weie average inventory, delivery performance, and 
inventory levels at the start of production The primary technical development was 
the application of S-Plus data analysts capabilities to the data 

With this model, materia! lead times had a dominant effect on inventory levels 
and committed inventory. Historically, forecasts were generally low, so for The 
historical data given, the planning cycle time used for the particular product had 
insignificant impac? compared to material lead times. There was greater potential 
for reducing inventory by reducing lead times than by reducing planning time Low 
forecasts increased backlogs. 

Current Modeling Activities 

We are currently finishing an analysis of a single-site manufacturing system where 
we mt& looking at how to improve the supplier response time The challenges in 



this application include managing a multilevel hfll-of-maienals and understanding 
the consequences of lo' as We are also working /, 

sector-level I ' stand tne consequences of proposed 

changes and explore alternatives 

Our enterprise modelinc es have evolved cc 

from our preliminary oroer-to-ship model However, there are still many more 
interesting challenges to address before we reach our goal of a computer-aided 
«?ss process design and operation sys- 

Project Manager 

Enterprise Modeling and Simulation Project 

HP iaboratones 
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This nonzero EOL inventory is significant because our 
safety stock policy targets zero safety stock levels in FGI 
and RPl at the end of the life cycle, Having observed I his 
phenomenon in the simulation, we wet€ able tosftowm&the 
matically why the EOI, inventory is noi zero. The format] 
derivation of this resnii is outside fche scope of the current 

paper, I ml more detailed analysis of the data shmvid thai il 
is the (lass C parts thai are lefi over. The Class C parts will 
be aero in the rase when orders come in as forecasted for 
the conditions of experiment only if the target RPl safely 
Stock for Class < parts is less than or equal to the 13- week 
leading average forecast Also, for I he conditions of exprri- 
nniit li, any part with target safety slock greater than 13 
weeks of L3-week leading average forecasi will enrl up wiih 
EOL material The hehavior of the amount < »f t i;ms c ! K( )L 
material as the number of weeks of target safety stork goes 
down is given in Appendix IV-3, and an informal explanation 
showing the reasoning behind the EOL material is given in 
Appendix IV- 1. 

The nonzero Koh is a function of the number of weeks of 
13-weefe leading average forecast l Ither techniques of com 

puling safety stock, for example using a cumulative leading 

forecast rather ihan the n-wrek leading average Forecast, 

niighi Nad Indifferent r< -stills. 

Smoothing WIP and Production, The initial spike in VV II* shows 
how the policy of starting production in week 19 (and not 



before) gives rise io a spike in capacity demand at thebegfn- 
ningof the produd cycle li could be eliminated by tncorpo 
rating production capacity constraints into production and 

malerial planning or by allowing FGI lo buikl up before the 
Hi si order comes lit l i < . before week 2) ;>. Both r if these 
require production to start before week l$* 

Experiment Set la: 

Single Uncontrollable Factor Variation 

In Ihe nomijial case, the customer order pattern was accu- 
rately forecast. We now consider the situation where the 
actual m (It 'is are different from ihr forecasts. 

Wp assume that customers Older according to a constant 
order forecast profile multiplied by some conslanl factor 
Actual/Forecast or A/F. A/F is the ratio of actual orders to 
forecast orders: its definition is shown in Fig. 6a In practice, 
marketing would change the forecasts periodically. Since we 
were noi modeling the forecasting process, we chose tin 
simplifying assnmpiion thai although a m-vv forecasi is gpj^ 

erated every week, it is identical io (lie forecast generated 

ihe previous week.t Here is an example of bias in the order 
forecast with no variance. The model interpretation is that 

although estimates wene wrong in the past, we expect thai 
future orders will be equal to the original forecast. This is 

t TJips is not a limiUtiun ui ttftjMdBl A user-specified forecast tan bo accepted by the modui. 
Latar models i i tied instoricai forecasts The reason for this assumption was to pt 

a better understanding of the effect of forecast bias Fluctuating forecast deviations make 
interpretation I 
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reflected in Fig, fib, Actuals came in as shown in the pari of 
i he graph to the left of the current lime, while the par? to the 
right of the current time line shows the current expectation 
of future ordere. 

Clearly, we would expect an effect when A/F is not 100%. If 
A/F is less than 100%, that is, if forecasts are high, FGI will 
start to build up T since production planning has directed a 
larger number of units t o be built than arc subsequently de- 
manded. Production planning and material planning take 
this into aceouni and plan m build loss and order less mate- 
rial in the future, but the overall material level is higher than 
when A/F is equal to 100%. un the other hand, if A/F is 
greater than 100%, that is, forecasts are low, FGI will start to 
be eaten away because production planning has directed a 
smaller number of units to be built than are subsequently 



demanded. Subsequently, production planning and materia] 

planning rake this into account and false &e production! hut 
since they are always estimating low future demand, we 
would expect the inventory level in general to be lower than 
in the case where A/F is 100%. Surprisingly, ihis intuitive 
result does not hold, as will bo seen later* 

We ran the simulations v\ itli A/F ranging from 50% tu 200% al 
equal intervals of^H/.':. j M jidditiOB, we ran 11 al smaller niifj 
vals in the region of Qo%to 125%. 

E0L Write-off* A consequence of keeping forecasts identical 
for all runs is that the consignment profile does not Change 
with reaped to &M Fig. 7 shows EOL metrics as A/F ranges 
from riO'i. to 300%. Note that the changes in value are not 
constant at toss the horizontal axis. Fig. 7a shows that total 
EOL inventory increases as A/F decreases. Fig, 7b shows 

rliat the percentage impact is even worse, simply because 
the write-off is a higher percentage when PC FT, which is 
directly Influenced by A/F, is lower. For low forecasts, thai 
is, A/F greater than 100%, the Hub inventory decreases. For 
high forecasts, that is, A/F less than 100%, the EOL inventory 
increases. The lower the A/F. ihe higher the EOL inventory. 

Fig, 7 leads to the obvious conclusion that inventory write-off 
can be reduced by the strategy of under forecasting orders. 
However, this is only one side of the story. The complete 
story is shown in Fig. S. 

Impacts on Time Series of A/F Changes. Fig. 8 shows the im- 
pact of A/F changes on cliff erent time series measures. To 
a vo id el ut tet we iv ill n o t sh ow i m mi to t y fo r co n s i(j n n i en t 
in subsi queni ti me series. FGI. WIP, RPI, on-order material, 
and on-hand inventory will refer to the material associated 
with trade units unless otherwise specified, 

All of the graphs in each row of Fig. 8 exhibit identical be- 
havior before week 2L This is to be expected, since before 
the first orders come in on week 21, the situation is the 
same lor all cases. Only as different amounts of orders come 
in on or after week 21 is the sii nai ion different for different 
values of A/F 

Fig, 8a shows the order forecasts and actual orders for ref- 
erence. The ratio of the values of the two Lines at any lime in 
the graph is equal to A/F. 

Fig< 8b shows the backlog and actual orders lime series on the 
same scale, Notice how ihe backlog increases spectacularly 
as A/F goes beyond 125%. Fig. 8c, which displays backlog in 
terms of mature demand, shows that for an A/F value - >l 
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201 f% the backlog can he as much as eight weeks of mat u n ■ 
demand. Backlog measured in terms of weekly mature de- 
mand is constant for low A/F. It increases for high A/F be- 
cause products cannot be shipped as last as orders come in. 

Fi^. 8d shows that the EOJL RPI level fulls as A/F increases. 
In addition, the general level of RPI as a function of time 
falls as A/F increases until A/F is greater than L50%, when 
the RPI level actually appears in rise as A/F increases, The 
reason is ihai because of shortages V \<> order more of alt 



material to build the shortfall in units, The short lead time 
parts show up first, but cannot be used because of a short- 
age of lite long lead time parts with minimal safety stock. An 
analysis of the results shows thai Khe eritica] part is A.3. 

Fig, 8e shows lhat the WIF profile it u noises as A/F increases. 
This is expected, since WIE 5 is directly related to I he ship 
ments flowing through the system, aifed the shipments are 
dirrefly related to orders, which are directly related to A/F 
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Remember thai this is true only when the production ea] 

iH < onslraint is not readied. Ifprodo* achy is only a 

lit lie greater than forecast, high demands won hi rest ill in the 
level of WTP being capped at some limit tout spread out over 
t irm\ 

Fig. 8f shows thai the Kr! lev^l is identical fur all values of 
A/F less than 100%. For A/F great erl ha n L0O94 ihe V(A gets 
eaten away slowly because the rate of replenishment of new? 
units does nol keep up with the shipments because of under- 
forecasting. However, since FG1 safety stock levels are based 
on two weeks of 13- week average forecast and the forecasts 
used are identical in all the experimental runs, the peak FG3 
tends to be the same. 

Fig. 8g, on-order material, shows initial large spikes for 
material for HP] and KG! safety stock, follower! by a drop 
after the material for safety stock lias been delivered. Sub- 
sequently the profile shows an increasing level over time as 
A/F incre;i 

Fig. 8I1. materia] ordered, shows the same spikes before week 
21 that we have seen before, Again the material ordered 
versus lime in ei eases as A/F increases. 

Fig. Si shows that, in general, committed inventory af'h'i 
week 21 is higher for higher A/F and stretches out farther 
overtime. For lower A/F the committed inventory is lower 
in ihe early pari of the life cycle, but there is an increase in 
EOt inventory. 

Fig. 8j shows thai for A/F less than 100%, shipments follow 
the order stream nicely, High A/F (lugh demand) values 
cause the initial orders to be filled as specified, but subse- 
quently shipments drop off and then catch up. The product 
shipment over time is smooth when A/F is less than or equal 
to 100%. When A/F is greater than 100%. during the early 
part of the life cycle the orders are filled as they come in. As 
the FGI safely slock is consumed, the shipments fall to the 
forecasted levels, and then subsequently tend to rise to the 
actual order levels, 

The on-time shipment graphs in Fig. Sk show that initial 
orders are delivered on time in all cases. For A/F less than 
100% (forecasts are high), all orders are delivered ottliiue. 
For A/F great er 1 1 tan I Of n% ( U > recasts are low) , initial u rde rs 
are delivered on time, but subsequent orders are late, As A/F 
increases beyond 100%, both the percentage and the total 
dollar value of on -time shipments (and consequently deliver- 
ies), go down, and the late orders never catch up. On-time 
delivery graphs, which are not shown, would be identical to 
on-time shipment graphs shifted by one week 

As expected, because of the policy of shipping as late as 
possible, Fig. 81 shows that average order-to-delivery time 
never goes below four weeks, but increases with time up to 
18 weeks as A/F increases fep 200%. Fig. Sm, showing the 
percentage Of on-time deliveries, is consistent with Figs. 8k 
arid 81 in terms of on- time deliveries. 

How Late Are Late Orders? Hnw late are the late orders and 
how many orders are delivered on time (namely, within four 
weeks of being ordered)? These questions are answered in 
Fig. 9, which show r s the dollar volume of deliveries and the 
order-tonie livery time. For A/F less than or equal to LOW 
( forecasts high or demand low), all orders are delivered on 
time. For A/F = 105%, nmsl orders an 1 on time. For 



A/F = 150% and 300% (forecasts low i some orders are deliv- 
ered on time, and a large fraction of orders are delivered 
late. Furthermore, for hjjgh A/F values, even though the total 
volume of shipments is higher, the amount of on-time ship- 
ments and deliveries actually goes down. Some orders are 
delivered as much as 14 weeks late, that is, IS weeks after 
receipt of order. This 14 weeks is the upper limit of lateness 
Iim i his particular model and data configuration. No matter 
how high A/F gets, orders will never be later than 14 weeks. 
The explanation for this is given in Appendix IV-5. 

Interpretation of Results- In this model, forecasts were not 
updated tin e 1 1 1 ■ basis uf orders. In reality, when orders are 
very much under or over forecasts, there will be pressure to 
Change the forecasts, If further information on the forecast- 
ing process is available, this can be incorporated into the 
model Another study that could be done is to see whal hap- 
pens if we treat the initial orders as early indicators of the 
w hole life cycle, that is, after some period of time, we revise 
the forecasts so that they more closely represent the volume 
of actual orders. On the other hand. If the life cycle is very 
short, it may turn out that revising the forecasts when die 
first orders come in may not have an Impact on system re- 
sponse. We have established a nominal trapezoidal product 
life cycle, but this could be changed In various ways. It 
could be stretched out horizontally to increase the life cycle 
i as is done in subsequent experiments), or vertically, bo 
show a higher level of product demand. 

Customers need to receive the products within a reasonably 
shorn time, or they might cancel the order. For ihe model, 
we assume that customers are willing to w T ait patiently as 
long as it takes for the manufacturing facility to produce and 
ship the products, and that they will not cancel Ihe order. 

The purpose of this detailed discussion is to show how 
changing the one factor. A/K can have different impacts on 
different metrics, and how this might affect different parties 
interested in the outcomes, A/F is partly under the control of 
customers, ami partly under the control of marketing, as- 
suming that greater effort will provide a better est i male of 
orders. It shows that if A/F is low. order processing and 
shipping would have excellent performance metrics in get- 
ting products out in a timely fashion, whereas material pro- 
curement would be in ihe situation of trying to explain why 
there is so much material in the plant, and marketing and 
the plant manager may have to explain why orders are 
below target. < >n the other hand, if A/F is high, customers 
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Factor Description 

Acrual/Foreca- 

Pan Safety Stocks 
Class A 4K weeks 
Class B SK weeks 
L6K weeks 

Life Cycle, L+0 months 

Availability, weeks 

Percentage value of 6, 10. and 
14-week lead time parts in the 
product (r%,s%,t%) 



Table 111 
Range of Values of Factors lor Different Experiment Sets 

Parameter Name Number of 

Different Values 

AF 11 



Values 



L 
Y 

It 



5 
5 

i 



'SftMXh 105.1 10. 120. 125. 
500 

K- 0.5.0."' 2.0 



V = L2A8J2 

m = ({WAG)*!* - 

sss- (0.100.0), tn = (0,0 ,1 00. 



Experiment (nominal case) Vafues shown in Italics 

Experiment Set la lurscontiulJable factor A/F vanep| Values of A/F varied as shown. Values of other factors same as expeffffltent D 

-ent Set 1 b {A/F = 100%, contra I fable factors van-mi): Values of factors other Than A/F varied as stwwn m lum Values of other factors same as in Experiment 0. 
Experiment Set 2 (dual-factor experiments). Values of factor A/F and one other factor varied in turn Values of other factors same as in Experiment 
Experimatf Set Ffall factors varied |- Value-s of all five factors vaned as shown 



will be screaming for products, order processing and ship- 
ping will be trying to placate angry customers, production 
will be under pressure to put out products faster, and mate- 
rial procurement will have to explain the perpetual shortage 
of raw material A. 3 while other material is piling up. 

Experiment Set lb: 

Controllable Factors Varied with 100% A/F 

We rtexl look at the effect of changing r 1 1 ■ - factors over 

which Mie i narmfact tiring ent erprise has some control hi the 

single-factor experiments, the variation of each laco »i is 

summarized in Table TIL Except for Hie set of runs where 

A/F varied as in ex peri men! la, A/F* was set at 100%. 

I Ihangea in safety stock levels can be characterized in many 
way* — tor example, for each part individually. We chose to 
multiply the safety stock kvels of experimnii bj a con- 
stant multiplier K whose value ranged from 0*6 to 2.0. Life 
cycle lengths were changed by using values of L to result in 
life r\r|,c lengths L+€ between 6 and 24 months. 

Availability Y was varied from 1 week to 12 weeks fit cannot 
he less than 1 week because of the I wef k shipment transit 
time). Y = 1 requires off-the-shelf delivery and implies a total 
build-to-forecast strategy As Y increases, the production 
strategy shifts front I mild-lo- forecast to huild-to-order. From 
prior considerations, an availability Y of 18 weeks will result 
in on-time delivery of every order regardless of forecast 
quality. 

While there are different ways to characterize modification 
of part lead times — for example, changing it for each part — 
we chose to change part lead times by changing the percent- 
age of parts with lead times of 6, 10, and 14 weeks to be 
t0O%fal (urn. 

EOL Results. The IS >L inventory graphs for A/F = 100% are 
summarized in Fig. 10. EOL inventory increases as safety 
stock increases; the results are consistent with experiment 

<). Wli'-n K is 0.75. we earry 12 weeks of C parts and Ihere is 
no EH H, RPI. When K is 1. we earry 10 weeks of C parts and 



end up with EOL inventory of C parts. When K is greater 
than 1, EOL RPI increases. When K is 2, we carry 16 weeks 
of B parts and EOL RPI includes both B am! < pari s. 

Ki<j. luh shows that product life length has no impact on 
EOL invent ory. This is to be expected in the model because 
increasing L stretches out the middle portion of the time 
series graphs, and the behavior towards the end of life tends 
to be the same in all cases when L increases (illustrated in a 
fur ure graph, Fig, lib). For short L, the effect of the rising 
demand En the beginning of the life cycle affects the behavior 
:ii the end of the life cycle. Fig. 10c shows that as availability 
Y is shortened, EOL invent or\ increases, that is, quoting 
shorter lead times to cusloi ises its to more risk of 

EOL inventory. This is intuitively correct; the longer the 
quoted availability, the longer we rati afford to wait before 
ordering material 

Part lead time has rm imparl on nl ory when A/F = 

ino'MRg. Hid i. 

Other Results. Fig, 1 1 shows the inventory measures over 
time as different factors are varied. Delivery performance is 
not shown because for A/K = 100%, delivery is always loir;, 
on time. 

I i_ L la shows 1 he inventory measures ■ >ver lime as a func- 
tion of raw material safety stock multiplier K. The heights of 
(he three initial spikes for material orders increase as K in- 
creases, directly impact RPI and on order material, and indi- 
rectly impact on-hand and con unit led inventories, hi general, 
the higher the K, the higher the invent ory levels, including 
EOL inventory, which is the I ail of the committed inventory 
graph. The on-order material level before the start oj pro- 
duction increases as K increases. Keeping all the other lac- 
lors constant, there is no change in backlog or delivery 
performance, and these are uol shown in Fig, 11a, 

Fig. lib shows the inventory measures over time for varying 
the product life cycle by changing L from to IS months 
Ihifl is one of rhe less iulereslirig graphs, shown here &Hf 
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completeness. EOL inventory is the same in all cases. How- 
ever, because total PC 1 FT im Teases. KOL inventory is a 
lower percentage of PC FT as L increases. 

Fig. lie shows the inventory levels over time for varying 
quoted availability X As Y increases, after the same Ihree 
initial spikes, the amount of materia] ordered gets delayed, 
and the on-order material graphs get stretched to the right. 
The committed inventory graphs are also stretched into the 
fun ire. The committed inventory is lower and the EOL in- 
ventory (tail of the committed inventory graph) tends to 
decrease. The delivery profiles are shifted oui into Bte 
future and (he backlog levels are higher. 

Fig. lid shows the time responses of the inventory metrics 
as pari lead limes vary. Nolu v ihe change in shape of the 
maleriiil ordered graphs, For ll - ( 25,40,35 J , there are three 
large and three small spikes, whereas for the other cases, 
there is one large spike and one small spike. As lead time 
increases, the material needs to be ordered earner. On-order 
material increases as the lead time increases. On-hand inven- 
tory does not change. There is no impact on EOL inventory, 
order backlog, or on-hand inventory (RPI+WIP+FGI) as long 
as A/F remains constant at 100%. 

Interpretation of Results. This set of results shows how r each 
organization in the manufacturing enterprise can improve its 
performance metrics assuming that il relies on the forecasts 
given as being accurate and does not try to second-guess 
them. For example, if material procurement is under pressure 
to lower inventory levels, it would naturally try to reduce K, 
On the other hand, order processing and shipping would 
prefer to reduce Y to reduce having to deal with impatient 
customers. 



Experiment Set 2: Dual-Factor Experiments 

In this experiment set. we varied two factors in combination 
and attempted to observe the effects. However, instead of 
looking at all combinations, we looked at the impact of each 
of the other factors when A/F changed This enabled us to 
see the ^n\-ci of the controlled action in various situations 
of customer ordering behavior. 

Results of Two-Factor Experiments. fug. 12 summarizes Hie 
information on EOL and on-time deliveries as A/F and other 
factors are varied. Fig. 12a shows that as K increases, there 
is higher exposure to EOL inventory' as A/F decreases. How- 
evert increasing K in general gives better delivery pcrfoi- 
mance by shortening the average order-lo-delivery time as 
VF inn eases above 100%. Below an A/F value of 100%, K 
does nol have an impact on the already excellent delivery 
performance shown by 0% late deliveries. 

Fig, 12b shows dial as L increases, Ihe infal shipments for a 
given A/F increase. For long L the absolute volume of on- 
time deliveries initially increases as A/F increases. As A/F 
keeps on increasing past 100%, the absolute volume of om 
lime deliveries decreases. The average order-lo-delivery lime 
is not affected very much by L, and the EOL inventory is im- 
pacted insignificantly. The absolute amount of EOL inventory- 
seems to depend little on L except when Lis 0. For L = 0, the 
long lead lime and high safety stock parts may actually cause 
most of the material for life cycle use to be ordered before 
the fust customer order is received. The percentage of EOL 
writeoff decreases for a given A/F as L increases, reflecting 
the fact that the EOL writeoff is a smaller percentage of the 
total shipments as total shipments increase. 
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Fig. 12c shows that increasing Y is desirable for reducing the in customers waiting for long periods of time, which in prac- 
pei centre Of Nte deliveries and reducing EOL inventory, but tire might lead 10 possible order cancellations. When Y = 1, 
that the average order-to-dclivery time increases, resulting the worst average order4n -delivery time is lower than the 
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best average order-to-delivery tiro*? when V = 12 week>. This 
is an example of a situation in which trying to reduce late 
deliveries by quoting a longer lead time actually lea< I 
longer average delivery times and possibly lower customer 
■satisfaction, 

Hg> I2d shows that if all other things are kept constant. 
longer vendor lead time leads iu poorer performance when 
A F ls gn L exposure when 

s less than 100%, F< 100,0,0), that is. lead time for 

ail parts is 6 weeks, A/F has little impact on average order- 
to-deliver>' time over the given range. Furthermore, the pri- 
ce mage of late deliveries is generally lower than foi 
other values of lead time. If Y could i i *r 

the case h = ( KHUU>)- no antes will ever be late, regardless 
of the value of A/F Applying reasoning similar ro that on 
page 82. the policy of wailing for customer orders to arrive 
before we order pans could lead to an order-to-delivery time 
i »f nine weeks, which is shorter than 12. 

Observations. We have looked at ibe interactions of A/F with 
the other factors In our experiments and noticed the com- 
plexity of the interactions. The results of experiment set 2 
show the impact of uncertain customer behavior on various 
organizations within the enterprise. In an uncertain world 
where A/F is outside our control, it wouid appear that in- 
creasing K and L reducing It. and increasing V would in- 
crease on-time deliveries, which is desirable from die point 
of view of the manufacturing enterprise. However, increas- 
ing Y will tend to increase order-to-delivery times and back- 
log volumes, w hirh could potentially lead to poorer cus- 
tomer satisfaction and high backlogs for order processing 
and shipping to deal with. 

The other problem of taking these actions is that while 
delivery performance for the enterprise improves in general, 
different people and organizations are responsible Tor in- 
lluencing and setting the values of K ? Y. and li and obtaining 
the reward of improved metrics, Increasing K results in bet* 
ter availability but Increased write-off, especially If A/F is 
iiHuu i on" One individual owns K H another individual owns 
Y, Hie vendors and R&D together determine It, marketing 
owns U and customers determine A/F. Any one of these can 
Influence the other measures unilaterally, so it is necessary 
to coordinate the efforts of increasing some parameters and 
red m ing others simultaneously. For example, material pro- 
curement could reduce K on the assumption that it will re- 
duce RPl, committed inventory and EOL inventory, and this 
would be correct if A/F wen- 100%. hut tf A/F came m 
greater than 100%, thr overall delivery performance would 
be poor. On the other hand, if H&l) chose longer lead time 
parts because vendors demanded a premium price lor slmrt 
delivery limes, EOL inventory would tend to be higher re- 
gardlessof what value of K was chosen by material procure- 
ment. If quoted availability Y were reducer I from 1 weeks Lo 
1 week, inventory levels would tend to go up. 

We COtild also consider the effects of the four other factors 
i m tine another, and that would give rise to another six com- 
binations. These discussions are outside the scope of this 

paper, 

Experiment Set F: All Factors Varied 

In experiment 0, we looked ill Ihe results of cme shnulai ion 

run. in experiment l. for each factor v\e looked <n tow to 



eleven runs. In experiment 2, we looked at 44 to 55 runs for 
each rombirtaJ u m of A/7 and the other facial As we study 
the effects of multiple factors, the number of runs i I 
exponentially. Complexity' increases not only in ten 
number of simulation runs considered but also the \va\ in 
which we analyze the data. A full factorial experiment that 
is ? one in which all e varied in ail combinations 

given here req malysis of 550X3 nuts, While it is 

'^rent lev I the 

amount of data generated as a result of increasing the num- 
ber of factors becomes intractable. For example, if all of the 
time series graphs of a single run were plotted on one sheet 
of paper each, we would have a pile ofprinfcoul 
reams of paper thick. To do the analysts, we used a graphing 
teclmique supported in S-Plus called a design plot.t 

Design Plots, Fig. 13 show's the design plots of the means of 
each of four different metrics at each of die le\ els i if the five 
factors. The four metrics are EOL Inventory, EOL invent ur> 
percentage, total on-time deliveries, and percem on-time 
deliveries Each plot reflects one metric and summarizes the 
value of tiiat metric for 5500 runs. The point labeled A is the 
mean of the EOL values of aH experimental runs with A/F = 
50% (mean of BOG values). A longer line indicates greater 
sensitivity of the metric lo that factor over I he range consid- 
ered, all other things being equal. For example, A/F appears 
to have the strongest Impact on EOL inventory, EOL per- 
centage, and on-time shipments. On the other hand, die raa- 
nuv demand period L has a strong influence on the total 
dollar volume of on-time product deliveries 

An interesting point is that mean EOL and EUL percentage, 
decrease steadily as A/F increases. On-time deliveries in 

dollars increases up to a point as A/F increases to 125%^ but 
subsequently decreases (point B in Fig, l'k I The explana- 
tion is that the safety stock policy gives sonic protection for 
on -time delivery in dollars when A/F> 10(1%. On lime deliv- 
eries as a ] >ercei 1 1 ag* s re n lai its at II 10% ft *r A/F £ 1 00% mid 

subsequently decreases as A/F increases over n>u% (point B' 

in Fig. i:Mj. 

Another iiilcivsliutf heliavioi is that of the points marked G 

and li The lad thai the mean values oi the metrics appear 
riose together for the (25,40,35) case and the (0,0,100) ease 
suggests thai Ihe length of the maximum lead lime ol parts 
in the bill of material has a very strong influence on on-time 
deliveries if all other factors are kept constant. 

Further Analysis. We have barely scratched the surface of 
what is possible in analyzing The simulation data of this one 
level bill of material, single-product situation, Further analy- 
sis and display of the variables js possible through scatter 
plots i »l pairs of variables ;iini responses* and the use of fac- 
tor plots which show greater detail. Foi example, further 
anaJysis could try fitting a statistical model using least sum 
of squares of residuals for the responses, separalely am i 
jointly. This was not done for this paper 

Experiment Set M: 

Multiple Product Life Cycles with Part Commonality 
This set of experiments showed the impact of part com- 
monality across multiple producl life cycles. Theproduci 

t We caN it a design plot because it is generated by the S Plus function plot-design Then 
standard name of this plot in the htararura fl it is naf ened to as a a plot ut ihu mean n p lie 
for each level of each faciei' " 
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cycles overlapped in time, that is, one started before the 
p re ceding one finished, and we looked at a series of scenar- 
ios Unit differed in Hie values of common parts in adjacent 
products. These were the assumptions: 

• There were four products: Adder-1, Adder-2, Adder-3, and 
Adder-4. 

• Part commonality occurred between arljacent products only. 

• Demand increased 30% for each new product. 

• The unit cost or each product was 85% of the unit cost of 
the previous product 

• Each product life cycle was 6 months, or L = 0, This means 
that the complete cycle for each product is 6 months, or 24 
weeks. 

• There was a one-month overlap between products, that is. 
the first month of demand of a new product begins in ttte 
last moutli of demand of the previous product. This implies 
a total lifetime of the product family of 21 months, or 84 
weeks. 

• Other factors and conditions remained as in the nominal 
case. 

Fig. 14 shows a graphical representational of the pan 
commonality between adjacent products for the different 
experiments. In particular, since part commonality for ex- 
periment MO is 0% across adjacent products, there are no 
shaded areas. A fuller discussion of parr commonality is 
given in Appendix 111 

Rg tS shows the forecasted and actual order patterns for 
the four products. 



Fig, 16 shows the HFI levels for parts used in the different 
products in Experiment M-0 (no part commonality). Con- 
signment inventories are nut shown to avoid clutter in the 
graphs. The Wlf^ FGI, products ordered, PC FT and delivery 
profiles are Identical tor all runs in experiment set \L How- 
ever, each of the runs has a different profile for RPI. Note 
the EOL inventory of each set of parts. 

Fig. 17 shows the consignment and EOL inventory levels for 
each run. As expected, the consignment level increases by 
product because the forecasted and actual orders increase 
by product, The consignment value for a particular product 
is the same across experiments. The rX.)b inventory for 
Adder-4 is the same in all the experhueuls. There does not 
appear to be any correlation between pail coimnonality and 
the EOL inventory. A correlation exists between part ob- 
solescence for a product and the EOL inventory for that 
product. 

Fig. IS shows the part obsolescence across products for each 
of the experiments. Notice how the EOL for each product in 
Fig. 17 is proportional to the obsolete pans for each product 
in Fig. lft 

Traditionally, in considering part commonality., design prin- 
ciples suggest using as many parts as possible from the old 
product. However, (he results above suggest that from the 
point of view of EOL inventory, the amount of leftover mate- 
rial at die end of each product is proportional to the percent- 
age of the part value of the obsolete parts in t he old product. 
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li lull her suggests that the important consideration from I he 
point of view of EOL inventory is that the percentage value 
of obsolete parts at die end of each products lite should he 
minimized. 

Discussion 

In this section we discuss specific results of the Simple 
Model, enhancements to the EMS system to do more de- 
tailed analysis, ihe role of die Simple Model in enterprise 
modeling and simulation, and optional ways of using 
enterprise modeling and simulation. 

The mayor results can he summarized as follows: 

• Rational material ordering and safety stock policies designed 
to reduce invent, my in zero at the end of the product life 
cycle can give rise to leftover material if customers orders 
exactly according to fo recast. 

• System behavior and the impact on different metrics such 
as write-off, delivery times, and performance deliveries can 
be quantified with respect to the factors of forecast quality, 
safety stock levels, material lead limes, product life cycles, 
and quoted availability individually as well as in combination. 
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• Forecast quality, which is influenced by the external envirqji- 
ment, lias a major effect on the metrics of interest For ex- 
ample, high inventory levels may occur when actual orders 
come in too high or too low, 

• The influence of pari commonality on write-off can be 
quantified; this suggests an al te mat Ave w r ay of looking at the 
practice of using common parts in a series of products. 

Whal have we learned hum the simulation runs on the Simple 
Model? We have derived a set of specific insights into system 
behavior under a variety of operating conditions using a 
methodology of generating behavior over lime. We went 
through a large number of scenarios and showed how to 
gauge system behavior front the perspectives of different 
parties. 

Interpreting the Results 

The model results are sensitive to the underlying assump- 
tions, Since we assumed the vendors always delivered on 
time in the simulation, the .safety slocks in effect guarded 
only against demand uncertainties. We examined in detail 
the situation of order fore< p ast I >i as with zero vari an c e . This 
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is not an inherent limitation of the model, but reflects only 
the del erministic circumstances in which we ran the simula- 
lirms. However; ihe results indicate that even if production 
and supplier Lead limes are completely predictable and sup- 
pliers deliver on schedule, interactions and delays within the 
system lead to long lead limes being seen hy the customers 
when there is underf ore casting of customer orders. The 
manufacturing enterprise needs to take this into account 
and start looking elsewhere — merely making the production 
faster and more efficient is not sufficient. 

The results so far have only scratched the surface of the 
analysis and interpretation possibilities* Olher analysis 
could be done by varying ship times, FG1 safety stock levels. 



production planning frequency, material ordering frequency, 
order filling policies, and uncertainty and time delays of infor- 
mal ion How. This increases the number of runs and the quan- 
tity of data collected as well as the complexity of analysis, 
but would provide a richer set of relationships, 

The Simple Model example may have left the reader with 
the impression that the current EMS system can deal with 
only simple or trivial cases. One goal of enterprise modeling 
and simulation research activities is to address successively, 
more complex interactions and to model real-world intrica- 
cies more closely. In support of that goal, the following sec- 
tions disc uss subsequent and future enhancements to deal 
whh other issues that have been raised. 
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Uncertainty and Variability. In the experiments described, the 
Simple Model was run under deterministic circumstances. 
Demand values and p roc ess times were constant across a 
particular run for convenience of understanding, and we 
considered uncertainty in the form of forecast biases where 
demands were a fixed multiple of forecasts oyer the period 
of the forecasts. Other forms of uncertainty could include 
rhe actual life cycle being different from the forecasted fife 
cycle. Uncertainly in process times could be handled by 
using two values for process times: the planned process 
time for planning purposes and the actual time for exeni 
tton. This reflects the situation when actual process thnes 
are uncertain and different from the estimated times for the 
jhi m ess. For example, the build time for planning purposes 
COUld be I wo weeks, but ii could turn om thai (he actual 
build I ime was one or three weeks. 

We did not deal with variances that might occur when the 
total demand is forecasted accurately but the week-to-week 
demand fluctuates widely. Furthermore, variances of process 
limes (e.g., delivery times from vendors and assembly times), 
yields (e.g., defective units), and build times for individual 
units were not modeled. 

Dealing with variances is fairly straightforward once they 
are characterized. It requires using random number genera- 
tors and multiple runs starting with different random num- 
ber seeds — the current practice of discrete event simulation. 
There are three primary' costs associated with this: the in- 
crease in data eollection to characterize the variances of 
different processes, the increase in computational eff<ni 
ami the increase in analysis effort. < mly the data for the 



model needs i" be Changed to relief 'I variances. The model 
structure itself requires no changes. 

Distribution and Multisite/Multiorganizational Interaction. The 
product distribution fuiu'tinn and iiiternrtion between multi- 
ple sites were riot considered in the Simple Model. Multisite 
and mult ior^an i/at ion interactions have been implemented 
by enclosing cloned versions of a slightly enhanced maun 
factoring enterprise model as shown in Fig, L9. The enhance 
ment requires the manufacturing facility Tn generate and 
transmit its projected material requirements in addil j< hi 1m 
material orders 

Capacity and Supply Limitations. In current practice, build 
plans and material plans are sometimes computed ignoring 
production capacity and vendor limitations. In some eases, 
these plans are adjusted to conform to production capacity 
and vendor supply constraints, such as a minimum order 
quant 1 1 v or a maximum that can be ordered in a period. In 
other cases, these limitations are observed at plan execution, 
I bat is, at production, or when deliveries are not received 
from vendors when expected. There is no unique way of 
dealing with these limitations. 

Implementing capacity limitations in the current Simple 
Model is straight forward during production. To deal with it 
dining planning requires the inclusion of two classes of ca- 
pacity constraints in the production planning algorithms: the 
caparit\ restrictions for an individual product, assembly uf 
subassembly as well as total capacity. and the rate at which 
production capacity can increase 
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In reality, when prospective capacity limitations are detected, 
production and manufacturing line design and engineering 
considerations determine the rate of capacity expansion. 
When gross overcapacity 7 is detected, consideration is given 
to reducing costs by reducing capacity. While currently the 
EMS system cannot model the strategic decisions of 
whether to expand capacity or forego extra orders, it can 
model the consequences of picking either of these actions. 

Interaction of Multiple Products. The Simple Model assumed 
a single product with unconstrained production capacity. 
Consequently, a single unavailable part stops production of 
that product. Since this phenomenon also occurs with multi- 
ple products with no common parts, multiple products with 
no common parts can he analyzed hy adding up the effects 
of the indhidual products separately. The reader familiar 
w nh linear systems will recognize &US 35 r i if prfricipte ul 
superposition 

Adding up the results would also be valid for multiple prod- 
ucts with common parts witii no part shortages as in experi- 
ment set M. It would not be valid for multiple products with 
common parts, resources, and supply and production capac- 
ity limitations under scarcity conditions. When a part or 
resource is in short supply, decisions must be made on how- 
to allocate the parts and resources based on some Simple 
heuristic or optimal allocation scheme. 

Multilevel Bills of Materials. The Simple Model dealt with a 
single-level BOM. Further expansions allow an arbitrary 
number of levels of BOM to be passed as data to the model. 
A seven-level BOM for a real product has been implemented 
and tested successfully. Tins capability to pass BOM as data 
allows us to make different runs with different product 
structures (as for example in experiment set M) without 
modifying the model structure. 

Connection to a Mathematical Programming or Optimization 
Package, The Simple Model focused on applying simple algo- 
rithms fur planning. The production planning and material 
procurement processes were initially implemented as the 



explicit closed-form solutions derived in Appendix t It w&& 
realized subsequently that these algorithmic dosed-form 
solutions were the solutions to the linear programming 
problem formulation. As more sophisticated planning deci- 
sion techniques are proposed and studied, implementing the 
algorithmic solution for each new (eehnique becomes im- 
practical An alternative approach is to formulate the plan- 
rung process as an optimization problem and separate its 
solution from the formulation. This leads to concent rating 
on ways to better formulate the problem, leaving the solu- 
tion In a separate process such as a mathematical program- 
ming package. This could provide a means of rapidly testing 
alternative strategies for production planning (e.g., global 
production planning across the entire enterprise versus 
local production planning at each site). 

R&D , Marketing, and Cash Flow. Fig. 20 shows a proposed 
enterprise mode) at a broader scope for the next level of 
complexity, It generalizes Fig. 3 which focused mainly on 
manufacturing activities. Modeling the marketing function 
(arid associated activities such as the forecasting process, 
pricing issues, and product obsolescence) could help show 
the impact of marketing decisions slid an hit it >s on the over- 
all system response as well as the impact of using current 
orders to project future forecasts, Modeling the R&D func- 
tion could provide insights on impacts on time to market, 
with product development time taken into account in addi- 
tion to build time. Modeling these functions can help us deal 
with situations thai require coordination of marketing. R&D, 
and manufacturing activities mid can help identify the exis- 
tence of leverage points for process improvement. The 
blocks shown in the diagram represent functions, and each 
could describe multiple instances of that function. For ex- 
ample, the block labeled manufacturing con Id represent 
multiple manufacturing sites interacting with one another. 

The primary flows in the Simple Model concentrated on inf or- 
joattim (e.g.. orders, forecasts, plans, and suit us information), 
material, and control (e.g., triggers that cause activities like 
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production to start). Flows and inventory- levels were con- 
verted to monetary units before being analyzed, but cash 
flows were not modeled explicitly. 

Mi deling cash flows for payments of parts, products, and 
process costs will provide a financial perspective. Shov 
projected cash flows and investments and the projected 
financial consequences of investment decisions will provide 
the stepping stones to doing discounted cash flow and net 
present value analysis. Modeling cash Bows wiJl also help 
generate pro forma financial statenb 
nue. cost, and income owing to different capital budgeting 
and allocation decisions, and provide a tool thai could help 
address business issues. An example of such an issue is the 
transition from a high -margin business to a low-margin high- 
volume business. 2 * The model may help by projecting cash 
requirements for investments and operations and providing 
estimates for return on assets during the munition* 

Whither the Simple Model and the EMS System? 

The Simple Model is not an end or final model; it Is inter- 
mediate in a series of models that have contributed to the 
evolution of enterprise modeling and simulation (seepage 90J 
and the development of the EMS system. Its simulation dem- 
onstrates the kinds of results that can be generated by enter- 
prise modeling and simulation, Its value is in providing greater 
quantitative analysis where previously qualitative approaches 
have been adequate (see below). lis immediate subsequent 
application was the planning calendar model. -^- fi ^7 

The subsequent and future enhancements discussed make 
the Simple Model more complete. Some of the changes 
make the model larger, add detail complexity, and gene? 
more precise results, Other changes broaden the scope of 
the model, and make it more representative of the other 
functions of the enterprise besides manufacturing; these 
changes require the addition of greater levels of abstraction, 
the ability to consolidate different points of view, and knowl- 
edge acquisition across the organization. All the changes are 
technically feasible and require different kinds uf activities 
the firs! set of changes requires greater emphasis on "model- 
ing in the small/ and the second set requires greater empha- 
sis on "modeling in the large* 1 (see discussion on page 81). 
Discussions based Gil the experience and views of some 
managers responsible for operations suggest that expanding 
the size by increasing the detail complexity, while providing 
greater predictability of the system, is difficult and requires 
a tremendous amount of investment to manage the complex- 
ity of the models and the generation arid interpretation of 
the resulting data, Monroe 2 J and Harmon-* have individually 
recommended that there is greater value and potentially a 
far greater return on investment to be obtained by broaden- 
ing the scope of future models to address and reflect business 
issues and concerns. 

Regardless of the direction of model enhancement is the 
challenge of managing simulation dala The simulation runs 
for the experiments generated large amounts of data, and 

only aggregate data was roller! ed and summarized, For in- 
stance, RPI levels for every part were generated for each 
week during the simulation, hut the data collected was the 
aggregate dollar value of all the parts* The challenge became 
one not of collecting all data, but one of deciding all e ad of 
I tin. which data was interesting and not collecting 1 1 in r 
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which was not; otherwise the storage requirements for stor- 
ing all the generated data became significant The data pre- 
sented in the form of graphs and charts in this paper is only 
a small portion of the actual data collected and analyzed. A 
larger amount of collected data was discarded because it did 
not look interesting, 

The sheer amount of detailed data that needs to he examined 
and interpreted tends to overwhelm the analyst. The analysis 
and interpretation of the data was very much a creative team 
effort requiring much discussion, and is not yet understood 
well enough to be automated. As we increase the number of 
factors, the (behavior I becomes more complex, and the 
amount of data lends in increase exponentially with Hie 
numb' [ mi factors When presented with the data in its paw 
form, decision makers and experts familiar with the problem 
issues but less familiar with modeling and simulation all have 
the same general reaction that it is too complex and difficult 
to understand. While this is a valid reaction, (he reality is that 
the enterprise is u complex system of interacting information, 
material, resource, and control flows, and u l.i-ih. r we like it 
or not. has complex behavior. Enterprise models as abstrac- 
tions or idealizations for the real system merely refleel that 
complex behavior in the simulation. We can choose to ignore 
the complexity of die real system and use ad hoc qualitative 
methods to deal with the resulting behavior, or we can 
choose to face the complexity, understand it by selecting 
what we tiiinkare import an I Factors that influence the be- 
havior of the enterprise, and rind opportunities for applying 
the understanding. Enterprise modeling and simulation rep- 
resent one means of facing this complexity and providing an 
understanding of this behavior As with most endeavors, w r e 
ham found I hat the precursor I o simplicity of expression is 
greater depth of understanding. 

increased technology in the hands of the modeling and simu- 
lalion expert is not siiffirieni lor providing the insight that 
will ltHp make better decisions and higlilight important re- 
Stilts. Merely generating huge numbers of insights and conclu- 
sions is Insufficient h requires the perspective of operations 
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h arijs and decision makers id guide the direction of explora 
nun ami to emphasize rh« ■•■mjth-i uteri tve Hie current 

situation, hi Tact., Monroe 21 has suggested, and we in the 
enterprise modeling and simulation project concur* thai 
techniques to digest and present large amounts of data rap- 
idly and in a more easily understood fashion would be a 
beneficial next step and a fruitful area of research, and thai 
joint work of a modeling expert with an operations team to 
further understand the issues of data reduction, interpret 
tion, ami presentation will help modeling and simulation 
lake its rightful plaee as a useful tool in analyzing business 
decisions, 

The Simple Mode] is a descriptive model that illustrates 
complex dynamic behavior of a manufacturing enterprise 
with low structural and detail complexity. As we have seen 
in this paper, its primary output is data and information on 
the state of the world, and it goes a great distance towards 
presenting observations. Unlike an optimization model, 
which is a prescriptive model whose solution recommends 
the best action under a given set of circumstances, the Simple 
Model does not suggest actions. It. is up to the analyst or deci- 
sion maker to come* up with creative solntii his to solve ihe 
problems highlighted by observations of the model behavior 
and then assess the results from a subsequent simulation 
nm incorporating those solutions. 

Prospective Applications 

Let us now look at application areas lor enterprise modeling 
and simulation, These include but are not limited to improv- 
ing the performance of the current system (continuous im- 
provement J. studying the impact of reducing process times, 
and generating information for the enterprise, all of which 
are discussed below, A potentially far more powerful appli- 
cation is looking at new designs where the process itself is 
being changed (i.e., reengineering). Because of the strong 
current interest, large impact, and controversy surrounding 
reengineering, this subject is given its own discussion on 
page 86. 

incremental Improvements. Actions for continuous improve- 
ment can be suggested by running the nominal or base line 
model and rerunning it with minor modification and changes 
in parameters or actions over which we have control. Fur 
example, it may not be possible to reduce all the part lead 
times down to six weeks, but w r e could certainly see the 
impact of reducing the value of 14-week parts in the product 
to determine the impact on the metrics of interest. We could 
look at the impact of reducing build times or FGI safety 
stock levels slightly to study the impact on the measures of 
interest. We could examine the impact of making two small 
changes at the same time. This application of enterprise 
modeling and simulation supports the process of continuous 
improvement by demonstrating the benefits of small 
changes. 

Verifying Impact of Reducing Process Times. Davidow and 
MaSoner" talk about how short cycle times attenuate "the 
trumpet of doom," which is a plot of forecasting error versus 
time that implies that the further a person must forecast into 
the future, the greater Ihe possibility of error Rather than 
speculate on or guess on the impact of this trumpet of 
doom, enterprise modeling and simulation provide a way to 
quantify the effect of reducing system cycle times. This can 



be accomplished b> making some estimates of the amount 
of uncertainties within the model 

Stalk and Hout : ^° suggest mapping out explicitly the major 
causes of problems in processes such as ru sw prod m r f devel- 
opment or in operations, and comparing actual versus stan- 
dard cycle times. These maps provide qualitative relation- 
ships. To the extent that processes can be mapped explicitly 
and quantitatively enterprise modeling and simulation can 
show how r the system behavior changes for a given change in 
the process and can verify whether modifying the component 
processes has the desired overall global effect. 

Generating Enterprise Behavior Information. Davidow and 
Malonc"'* identify four categories of information of use to a 
corporation: content, form, behavior, and action. Content 
information is historical in nature and reflects the experi- 
ence. Form information describes shape and composition 
and is usually more voluminous than content information. 
Behavior information often begins with lonu information 
and usually requires a massive amount of computer power 
to predict behavior through simulation. They suggest that 
the final triumph of the mformation revolution will be the 
use of action information — information that instantly con- 
verts to sophisticated action. Until recently, only the most 
elementary 7 category, content, has been avail able to business 
in any systematic and manageable way, and obtaining or 
generating the other three categories has become economi- 
cally feasible only in recent years. They go on to describe 
how behavior infonuation generated by computer simulation 
is the new paradigm for product design ranging from molec- 
ular design through automotive design to airplane design. 
With such behavior information design disasters of the past 
n ugh I b e averted , an d p ol en t ia I ai u I 1 1 u f o rese en f u t u re I rag- 
edy can be replaced with a successful and predictable con- 
clusion. With the arrival of workstations in the 1980s, it be- 
came reasonable for the computer to create realistic moo* els 
and put: them through their paces rather than painstakingly 
building prototypes and testing them under a variety 7 of op- 
erating conditions. High-speed simulators could be built that 
reproduced the actual electrical characteristics of devices in 
di lie rem con figu rat tons. 

We suggest that, enterprise modeling and simulation repre- 
sent an assistive and enabling technology Tor the design and 
Implementation of processes of the enterprise, and that the 
application of such techniques to the enterprise could poten- 
tially have greater impact than product design. Furthermore, 
these techniques have the characteristic of converting con- 
tent and form information into behavior infonuation on 
which action can be taken, While the enterprise modeling 
and simulation process i nrrently does not suggest actions 
or alternatives, it describes the behavior of the system de- 
signed with alternate processes under Afferent operational 
scenarios. 

Conclusions 

In this paper, we outlined activities in enterprise modeling 
and simulation at HP Laboratories and presented in detail the 
results of the simulation of a simple model of a manufactur- 
ing enterprise. We have also described possible areas where 
enterprise modeling and simulation might be applicable, and 
reiterate that enterprise modeling and simulation provide a 
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way of quantifying the impacts of proposed changes before 
they are implemented 

The Simple Model captures the characteristics and behavior 
of a manufacturing entity at a fairly high level It shows that 
in the best of circu instances (e.g.. customers ordering ex- 
actly according to forecast), seemingly rational operational 
policies can lead to end-of-life inventory. The situation only 
gets nunc complex as greater uncertainty is introduced, 

Experience with using the Simple Model suggests two direc- 
tions for future research in enterprise modeling and simula- 
tion. The first is to expand the scope of the Simple Model to 
more completely represent thf functions and organizations 
and their interactions in the enterprise. The second is to 
improve the process by which the data generated by the 
simulation models ran be understood and summarized, and 
the resulting information presented in a form thai permits 
decision makersjo understand more completely and i<* ati 
more rapidly and with greater assurance that the desired 
objectives wiU be achieved. 
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Appendix I: Mathematics of Production and Material Planning for the Simple Model 



1*1 The Planning Function 

The planning function is actually an analytic model embedded within 3 discrete 
event simulation mode!. The fundamental principle on which the production and 
material planning algorithms are based is the conservation of mass, that is, con- 
sumption cannot be higher than the total supply available. Trie order in which me 
build plan computation is done is the reverse of the order in which subassemblies 
are built and products are shipped (i.e , from shipment lo product build to part 
order). For ease of explanation, the current week is considered to be week 0. This 
derivation emphasizes clarity of explanation rather than rigorous detail 

There are three sets of decision variables to he determined for each week: sitl the 
shipment plan, b{tj. the build plan, and frjfrf, the materia! ordering plan These are 
shown in italics 

Before we get into the mathematical formulation, let us first look at the process of 
computation. Fig 1 illustrates how the production and material planning algorithms 
work in this model The computational process is described in the following order 

■ i-Z describes the notation shown in Fig. I 

• 1-3 describes the safety stock computation 

• 14 describes the initial conditions for computation 

• 1-5 describes the cnmpuLatrort or the shipment plan. 

■ 1-6 describes the computation of the build plan 



» 1-7 describes computation of the number of units started this week 

> 1-8 describes the computation of the material consumption and material ordering 
plans. 

» 1-9 describes the actual material ordered this week 

■ 1-10 describes the computation of the number of weeks for each of tha plans. 

1-2 Notation 

y n, s. t = indexes for week number Icurrent week = U\ 

' fit I = Current forecast of product orders for week t, t = 0, 1 Mf 

^t} = FGlatendofweekt 

■ Wit I- WIP at end or week t 

> B|t) = Backlog units at end of week t 

y B|t,s) = Backlog units at end of week t having shipment dates in week s 
y ${t)= Planned shipments during week t 

> b(tj= Units planned to be started during week t 

> B ^ Build time m number of weeks 

y Y = Quoted availability in number of weeks 

y S = Shipment or transit time 

y\ = Index relating to part 

y Qj = Quantity of part j per unit of product 

y qj(t) - Planned consumption of part j during week t 
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Ftg. 1. Nutation and production/material 
planning. The shipment plan is computed from 
tne backlog, forecasts, quoted availability, and 
transit time, the build plan is computed from 
the shipment plan, the build time, WIP. FGI, 
and FGI safety stack. The actual build is conv 
puterJ from the build plan and the material 
availability. The material consumption plan is 
computed from the btiiSd plan and the bill of 
material The material ordering plan is com- 
puted from RPI. RPI safety stock, the materia! 
consumption plan. orHffi& material, and lead 
time 
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• - - - : :'-..: :.'.'". of material] to be ordered during weekt. t = Q. 1 

• fljltl = Rfi of pan i at the end of week t 

• ■ = ■ rj partjfeEfl .eefct 

-- Units of part j on order at the end of week t 

■ !_> = Vendor iead time fc r 

• J = Set of parts Trial $ 

• - rety stock in - and 

• V ( = HFI safety stock of pan j in wee^ of demand 

■ N s = Last week for computing shipment plan 

• ' . : : • citing build plan 

• N; = Last week used foi forecasts 

• Nj- = Last week for computing material order for : ■ 

Since the current week *s 0. the values of these variables represent actual values 
for weeks before 0, and the values are computed, set, or derived for weeks and 
later. In particular, the values of variables at the end of week -1 represent the 
current values of those vananies. as described in I-4. All numerical quantities 
except rime indexes are zero or positive 

1-3 Safety Stock Computation 

Safety stock is expressed in number of weeks of 13- week leading average forecast 
The 13-week leading average forecast at the end of week t is defined as: 



f(t) = ^Vf(t-M| 



III 



The target F6I safety stock at the end of week t is w weeks and the target RPI 
safety stock at the end of week t for part j is V, weeks. The expressions for these 
quantities are; 



Rt) = wflt) 

hjti = vnl 



(2) 
(3) 



Mm intra sink n = 

- - • 
sucotha: '_ * 8(-1,t)+ ][ ft 



- 
and sin) > 



- 



These equations define a series of(N s * l ) linear prsgrarawig problems However. 

a set of fe= rts. and the optimal 

le solutHFis cm be expressed in closed forrr 



«wH 



] B\ - for n = 

Bi - " f or < n < ¥ - S 

- - - S)| f or n > Y - S 



15) 



The term (Y - S) is the difference between the quoted availability and the transit 
time |i.e , the order-to-ship time to achieve on-time delivery), and indicates the 
time in the future after which shipments depend solely on forecasts, 

1-6 Build Plan 

The bm IrJ plan, which indicates how many units are to be started in the current 

week and succeeding weeks, is based on the assumption that the FGI levels at 

the end of weeks 0.1 B-l have afready been determined by the current FGI, 

WIT 1 and shipments preceding week D. It further assumes that we might be able to 
control FGI at the end of week B or later by deciding how many units we start this 
week and future weeks, that is. by controlling b(Q) r b(1L...M We want to keep 
the AftrJas low as possible but greater than or equal to £1, such that the total planned 
build during weeks through n must be greater than ar equal to shipments during 
weeks through B+n plus FGI at the end of week B+n minus current FGI and WIP 
The complete formulation is as follows: 

Minimize dMn-0.1,.,. f Nt] 



1-4 Initial Conditions 

■ FH ) - Actual FGI at the end of the previous week, that is, current FGI 

► Ml ! I = Actual WIP at the end of the previous week, that is. current WIP 

i OjHl a Actual part j on order at the end of the previous week, that is, current 
on-order material 

► R,l — 1 ) = Actual RPI for part j at the end of the previous week r that is. current RPI 
for part j 

■ BHI = Order backlog in units at the end of the previous week, that is, current 
backlog: 

BM)= £ K-U] (4| 

tC^II shipment dates in current backlog; 
• Bl-T.s) * Component uf currant backlog with shipment date in week s 

1-5 Shipment Plan 

The shipment plan indicates prospective shipments during the current and future 
weeks It is computed on the assumption that customer orders ere not shipped 
before they are due. but are shipped in time to satisfy the quoted availability 
retirements. This implies that For any week, the orders planned to be shipped are 
those that are already late ii.e., should have been shipped in an earlier week] and 
those that must be shipped to be delivered on time Notice thai m computing the 
shipping plan, we do nnt take into account the amount of inventory an hand or in 
process. This is representative of the way shipment plans are computed and then 
subsequently checked against reality. 

Put another way. this can he expressed as planning to ship the minimum quantity 
in each week that will satisfy the quoted availability criteria. The problem can he 
formulated as shown in the set of equations he low, which indicate that we are 
attempting to minimize shipments in the current week, current plus next week. 
currant plus next 2 weeks, and so on such that the total shipments in those weeks 
is greater than the current existing backlog whose shipment date is already past 
or in those weeks, plus the forecasted orders whose desired shipment dates lie in 
those weeks 



such that ]T Wa S s(t3 + RS + n)-F(-t)- Wf-1) 

i-ii r = Q 

and bfnj>Q. 

Again, the above is a series of (N ft +1) linear programming problems, with optimal 
feasible solutions that are expressed m closed form as follows: 



- max 



fcjr^r n-1 

0. F(B + n) + ]T s(t) - Ft - 1) - W( - 1 1 - ^_ 

t=o 



t=rj 

forn = QJ 

To summarize the above, the current build plan should look as follows: 
Week: I 2 ... n 



(B| 



Planned Build. bffl bfl) m 



bfnl 



1-7 Actual Units Started 

The actual units started this week, brj, will be b(G) if there is sufficient material If 
there is insufficient matersal the actual units started is the maximum possible with 
the available matenai. or 

Msjomrze b{j 

suchthatOjbD^R^ll + rjtO.VjEJ 

3ndO<b u <M 

for which the closed form solution is: 



M(-1| + rJ0|\ 
mimml- 3 — — 1 



(7) 
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1-9 Material Requirement Analysis 

If the lead time far a part j is Lj weeks, the RP1 levei for part j at the end of weeks 
0,1, ... Lj-1 has been determined by material on hand, material an order, and 
projected use. We could control RPI far pert j at the end of week Lj or later by 
deciding how much of part j we order in this week and subsequent weeks. The 
estimated material consumption during a week is the quantity of the material for 
the build for that week, that is 

p=Cpft( (8) 

The material ordered during weeks through n must be greater than or equal to the 
material consumed during weeks through Lj+n plus the desired safely stock at 
the end of week Lj+n minus the cogent on-hand material and the current on-order 
material This can be expressed mathematically as follows; 

Minimize nij(n), n = 0,1 Nj, f&J 



TJ — Ojf— 1) 



El t 

such that ^ mflf > ^ qj(t r + fi^L, + n] - R^- 

and mj{nj^ 0. 

After substituting equation 8, this becomes a series of linear programming 
formulations for which the closed form solution is: 



fo 



mM = wti&i 



t, 1- n 



Qj Y W'+ R r( L i + n ) " Rjl" 1 ) 



t=a 



(9) 



1 = 



) 



fnrn = G r 1 r ....Nj.jeJ. 
The current material ordering plan is shown by the following table. 

Week 








1 


2 


Material 1 


miffl 


tftfW 


mffl 


Material? 


m 2 {0) 


m?(i) 


m 2 (2} 



Material j 



00 mid) mJ2) 



n 

tn 2 (n} 



nJflfi) 



1-9 Actual Material Ordered 

Given the table above, the actual material ordered in this week must be mJOl 
VjeJ. 



MO Determination nf the Required Number of Weeks 

Since we want to compute the material procurement plan for materia] j for periods 
through Nj, we need to make sure we have values of the forecasts, shipment 
plan, and build plan far enough in the future to allow us to do so This section 
shows how many periods of those plans we need to compute. 

In 10 through 16 below, "m s {nj requires xlnj" should he read as, "Computing mjfnj 
requires values of x[0J, xU), .-.., x{n)." Thus ID should be read as. "Computing 
mjtNj) requires the values of fyO), faille RjiLj+N { )." 

From 9, 

mj(Nj) requires RjjLj + Nj) 

and ry(N f ) requires bfl^ + NJ. 
FromlQ, 3, and I 

tf}-/A(AequirestUj + Mj + 13). 
From 1 1 and 6, 

m./Aj.irequjresRBtLj + Nj) 

and rnjfNjf requires s{8 # L f + M, 
From13, 2, and 1. 

mjNJ requires f(B + L, + Nj + 13) 
Frum 14, 5, and 1, 

^^/requiresf(B + Lj + ^-(Y-S)|, 
Computation of % From 1 1 H 



Ni 



= max! 



*4*m 



Computation of N s . From 14. 



Ms = max B + L, 4- N, 
[ejl J 



Computation of Nf. From 12, 15, and IB, 

r L, + Nj + 13 
N f = max J B -h L] H- N, + 13 



JEJ 



(IS) 

mi 

(12) 

m\ 

(14| 

m 

(16) 
(17} 

(181 



(19) 



B + Lj + Nj - (Y - S) 



Since B ^ 0. [Y- S| > 0, the middle expression dominates, and 19 reduces to. 



max B 



N t = max B + L, + N, + 13 



ieji 



j r '"j 



(20) 



Appendix II: Weekly Event Sequence 



n the following tab 


le, periodically schedule 


»d events are show 


Event Time 


Event Frequency 


Initiators 


Monday 1 :0D 


Weekly 


Customers 


Monday 8:00 


Weekly 


Factory 


Monday 9:00 


Weekly 


Factory 


Monday 10:00 


Weekly 


Factory 


Monday 10:00:01 


Weekly 


Vendors 


Monday 10:30 


Weeklv 


Factory 


Friday 16:30 


Weekly 


Factory 


Friday 23:58 


Weekly 


Simulation Exec 



Event Description 
Generate and send orders; these orders are received by the Adder factory at 9:30:00 the same day. 
Completes computing FGI safery stock for future weeks. Completes computing shipment plan and 
build plans. 

Completes computing material requirements plan Completes computing material procurements plan. 
Generates current week's material orders. Material orders arrive at the vendors instantaneously, 
Finish filling and shipping orders due this week Shipments arrive at the factory instantaneously, 
Begins current week's production. Completes production started two weeks ago. 
Completes filling and shipping orders for the week. 



Simulation Executive Records values of all the state variables. 
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Appendix III: Details of Part Commonality Experiments 



v MC 
material cos*, with uppercase rjenouno, dollar values and lowercase 
denoting pev terial 



Common to products 

i and H 

Uniqur- I 



Common to products 
i and 1+1 



Set of 
Material 



Value of 
Material 



MC, 






MC M 



MC, w 






= 



Percentage 
Value 



MC: 



x 100 



MC M 
MC7 



x 100 



MC, j $ i 
mc lil+T = -^— x TOO 



Commonality occurs only between adjacent products Ttos implies that a part can 
bo used jn at most two products. 

Each of the MC; if is further broken up into class A, B. and C parts wrth relative val- 
ues 50, 3D, and 20 percent. Each of these classes is made up of 6, 1G r and 14 week 
lead times with relative values 25, 40, and 35 percent. (See Table I on page S3,) 

At the end of the product i life cycle, obsolete inventory (if any) should come only 
from parts in sets m, , and rrij ,_i. Any leftover parts from m ut1 can be used in 
product 1+1 This implies that msy^ and mCjy impact the obsolete inventory at the 
end of the product life cycle for product i 

The values shown in the following table should be derived from the real bill at 
materials, for our experiments, we reverse the process, that is, we generate a bill 
of materials from the table, which was generated heurisiically from the experi- 
mental scenarios, wrth the following constraints on the values of mc 



• For each i and j . mc, , must be greater than or equal to and less than or equal lo 
100 

• For each \, the sum of meg over all j must be 100. 

zero, then mc^ , most also be zero. 

Description of Experimental Scenarios 

Run M-0: no part commonality at all between adjacent products 

ftun M-1: 20% pancc- duds. The pans con 

to products i ami i+1 make up 20% of the part values of both product 

en by a reduction in either part quantity or part cost, but the reason is not 

reflected in the dollar value of leftover inventory or material 

Run M-2: 2Qtt part commonality when moving to a new product. The parts com- 
mon to products i-l and i make up 20% of the part value of product i; the rest of 
the value of product i is split equally between the parts unique to product i and 
those common to products i and i+T Since product Adder- ] has no prior product, 
the value is split equally between unique parts and parts common to Adder- 1 and 
Adder- 2. 20% of the value of Adder-2 is made up of parts common to Adder-1 and 
Adder-2; the remaining B0% is split equally between unique parts and parts com- 
mon to Adder-2 and Adder-3 20% of the value of product Adder-4 is made up of 
parts common to Adder-3 and Adder-4; the balance of the value is unique parts 
since there are no succeeding products. 

Run M-3; 50% and 25% part commonality between alternate products. There is 
50% part commonality between products Adder-1 and Adder-2 and between 
Adder-3 and Adder-4, there is 25% part commonality between Adder-2 and 
Adder-3. 

Run M-4: 50% part commonality between adjacent products; no unique parts in 

Adder-2 and Adder-3; 50% unique parts jn Adder' 1 and Adder-4 

Run M-5: 30% part commonality between succeeding products. 



Part Commonality Data (%) for Multiple Product Crossover 



i 


Product 


Demand (units) 


Product Cost (St 


Common Parts i%\ 






Experiment Run 
















M-0 


M-1 


M-2 


M-3 


M-4 


M-5 


1 


Adder-1 


V 


10,000 


mc--, 
mc- ;.; 


100 



B0 
20 


50 
50 


50 
50 


50 
50 


20 

80 


2 


Adder-2 


1.3V 


0.65x10,000 


mC|j 

INI I 

mc 2.3 




100 




20 
60 
20 


20 
40 

20 


50 

25 
25 


50 



50 


80 
10 
10 


3 


Adder-3 


1.3 x 1.3V 


0.85x0.85x10,000 


rnc 3>2 

™3.3 

mc 3 4 




100 




20 
60 
20 


20 
40 
40 


25 
25 

50 


50 



50 


80 
10 
10 


4 


AddeM 


1.3x13x1.3V 


0.85 x 0,85* 0.85x10,000 


mc43 

mC44 




100 


20 
SO 


20 
80 


50 

B0 


s 

50 


B0 
20 
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Appendix IV: Details of Explanations for Experiments and la 



IV- 1 Estimated Financial Impact Based on Theoretical Considerations for 
Experiment 

The impact of product Adder on the financiaf situation of the enterprise, as 

explained on page 89, is: 
■ Total PCFT = $7,800,000 

> Mature volume * MV * maiure PCFT * Sa00,0QQ/month or S200 f 0DQ/week 
i Consignment inventory = S300.000. 

IV-2 Mature Demand Week Considerations for Experiment 
RPI Material lo Support Mature Demand 

Class A Class B Class C All Classes 





Percentage of Part 
Value in Product 


50% 


30% 


20% 


100% 


I 


Weekly Use during 
Mature Demand 
<DxMV 


$100k 


S60k 


S40fc 


S200k 


% 


RPI Safety Stock in 
Weeks 


4 


B 


16 


m 


*■ 


RPIinS *xMV 


$400k 


S4B0k 


$640k 


El 520k 


6 


RP3 in Weeks of MV 
8 ^MV 


2 


2.4 


3.2 


7.6 



On-Order Material tn Support Mature Demand 
CD Lead Time 6 weeks 10 weeks 14 weeks All Parts 

Z5% 40% 35% 100% 



2 1 Percentage of Pan 
Value in Product 



E$ Weekly Order during $50k 

Mature Demand 
■ MV 



$80k 



S70k 



i: Amount on Order = 
Weekly Order x Lead 
Time: (?,■ x 



S30Qk 



$800k $98Gk 



$Z00k 



$2TO 



® Percent Value of Part 14.4% 38.5% 47,1% 100% 

on Order. -3) + $20BOk 



@ On -order Material in 
Weeks of MV 
€)*MV 



1.5 



40 



4.3 



10,^ 



Total Inventory Metrics during Mature Demand 







Weeks of 


Dollars 






Mature Demand 




.1 


RPI 


76 


SI 520k 


% 


WIP 


2,0 


S4D0k 


s 


FGI 


20 


S4D0k 


=?. 


On-Hand Inventory: | i ■"■ . 


11.6 


S2320k 




On-Grder Material 


10.4 


S2080k 


§ 


Committed Inventory ® + © 


22.0 


$44O0k 


I 


Consignment Inventory 


15 


S300k 




Total Committed Inventory $+® 


23.5 


S470Dk 



IV- 3 End- of- Life Considerations for Experiment 

Total PCFT = $7,800,000 Net profit = $78,OQ0(i/1QQ). where i is the profit as a 

percent of PCFT, 

Trie following tabJe summarizes the impact on the profitability of various margins t, 

Write- Off as a Function of Profit on Shipped Units 

■ F-oftt Margin i 5% 10% 20% 30% 

S390k $7B0k $1550k $2340k 



I Profit from Trade Units 
S7.8P,- 

% Leftover Material 



$64,615 



I Leftover Material as % Of Net 16.57% 8.25% 4,14% 276% 
Profit -® + @ 



d$ Consignment 



$300,000 



® Consignment as % of Net Prof it 76.92% 38.46% 19,23% 12 82% 
t ® 

© Total EOL Material as % of Net 93.49% 46.75% 23 37% 15 58% 
Profit ( 3 ■ 

The following table shows the impact on Class C EOL material of reducing safety 
stock levels, These results were computed using means other than simulation. 



Weeks of Class C Safety Stock 

16 weeks 
15 weeks 

14 weeks 
13 weeks 



Class C EOL Material 

$64,615 
$35,385 

$13,846 
$0 



IV-4 Why There Is Class C material Left Over for Experiment 

The last period in which we expect to receive orders is week 68 The end of week 
55 is 13 weeks before the end of the product life cycle. From the Adder order fore- 
cast in Fig. 2 on page 83 and the target RPI safety stock lor class C material being 
16 weeks of the 13-week leading average Recast (Table lb on page 83.1. at the end 
of week 55 the amount of class C material in RPI should theoretically be 16/13 of 
the total demand to the end of I ffe. or [ 1 6/13) x (1 Vi x V) = (26/1 3! x V units, 
where V - 80. 

In week 55. we need to start building the units for orders received in week 55 
Ignoring the current FGI, the maximum new build from week 56 to the the end of life 
is equal to the demand from week 55 thmugh the end of life, that is, 2 V. Thus, at the 
end of week 55, there is more class C material on hand — enough to build (28/13) 
x V units — than needed for the demand to the the end of the product life cycle. 

Remember that we did not consider units in FGI, If we want to reduce FGI units 
down to by the end of the product Eife cycle, the total new build must he less than 
that computed above, and hence there will be even more class C material left over 

In summary, one reason for the leftover class C material is that the safety stock 
computation requires holding more Class C raw material in RPI 13 weeks before 
the end of life than can be consumed by orders received in the last 14 weeks of 
the product life cycle. 

IV 5 Why Orders Cannot Be More than 14 Weeks Late for Experiment 1a 

Assume that an order comes in during week jc In the worst case we have not yet 
ordered any material for the unit that goes with this order The earliest the material 
can be ordered is week x+1 , and the longest lead time part will be delivered during 
week (x+1 )+ 14, which is week x+1 5. Since build time is 2 weeks, the unit is ready 
in week x+1 7. Since transit time is 1 week, the unit is delivered to the customer m 
week x+1 8 Since the quoted availability is 4 weeks, on-time delivery means the 
customer should receive it in week x+4 Tnis means that the lateness is 14 weeks. 
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HP-PAC: A New Chassis and Housing Concept for Electronic Equip- 
in en t , J oh a u n CS Mtdtn.J ti t ye 1 1 Hahei If, Si ey fried Kopjt. and Ti tn 
& fmegkr 

High-Speed Distal Transmim-r Characterization Using Eye Diagram 
Analysis, Christopher M. Millar 

Thermal Management in Supei critical Fluid Chromatography, 

( 't't/nif XuthtiH atff! Barbara A. Hackbarth 

What is SFC? 

Linear Array lYansducers with Improved image Quality for Vascular 
Ultrasonic Imaging, Matthew G, Moonetf and Martha Grewe Wilson 

Struct tired Analysis and Design in the Redesign of a Terminal and 
Serial Primer Driver, Catherine L Kilciits,< 

I j;iin-l driven Tesl Systems, Adeie $, Londis 

October 1994 

Customer-Driven Development of a New High-Performance Data 
Acquisition System, Von C Campbell 

A Compact and Flexible Signal Conditioning System for Data 
Acquisition, John M. da Can ha 

High-Throughput Amplifier and Analog- to-Digital Converter, 

H>>u<drfJ. Riedel 

Binary Ranges Speed Processing 

I M i - 1 h e-Fly E ngi neerii ig U i t its Con ve rsi Q 1 1 , Ch I is 1 1 ij ih ei ' P. J. Krffy 

Bui II -In Self-Test and Calibration for a Scanning Analog-to-Digital 
Converter! Gerald I. R&akand Christopher PJ. Kelly 

A Hierarchy of Calibration Commands 

Manufacturing Test I Jplimi/ation for VXl-RaAed Scanning Analog-!o- 
Digital Converters. Bertram S. Kalis ami Rodney K, Village 

Design Leverage and Partnering in the Design of a Pressure Scanning 
Analog-to-Digital Converter, Richard E. Warren ami Conrad R. Pnjfi 

Integrated Pin Electronics for Automatic Test Equipment, James W. 
Grace, David M. DiPietro, Akito Kishida, and Kcnji Kinsho 

CMOS Progranmiable Delay Vernier, Masaham Goto, James Q. 
Barnes, ind Ronnie E. Owens 

Theoretical Approach to CMOS Inverter Jitter 

Real-Time Digital Signal Processing in a Mixed-Signal LSI Test 
System t Keif a Gunji 
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(>]<>ssary 
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Analyzer, Snnit BimL Bob Kr'ohofft, and Anne L Drieshnch 

FDD I Topology Mapping, Sit nil Bhat 

A 1 11 tii nation of Electrical Overstress Characterization for 
Semiconductor Devices, Carlos //. Diaz 

December 1994 

Fast DDS-2 Digital Audio Tape Drive, Damon R. Ufi:arosy 

DDS-i? Tape Autoloader: High-Capacity Datastorage in a 5%-Inch 
Form Factor Sfeien A. Diniond 

Autoloader Control Electronics 

Autoloader Firmware Design 
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Automatic Slate Table t ,i m uirion, Mark J. Silntirs 

Using State Machines as a I icsign and < oding Tool. Ma tit J Simms 

An Event-Based, Retargetable Debugger, .4 run K. hji'u>t"i: 
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John R, Vasfa 

Compiler ( Jpt imitations and Debugging 
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Joy Xiao H>i W 
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Estimating the Value of Inspections and Early Testing for Software 
Projects, Louis A. Fmn^ and Jonathan C Shih 
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Tolerance Mechanisms in Clock Distribution Networks 
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A 

tract lest site 
Accuracy, media dri\> 
stic impedance 

Actual-to-forecast ratio : j . 

Algorithm, logical mapping 10 

Algorithm, physical mapping ..,,102 

Alignment, print cartridge 3 

A-law and u-Jaw data formats 62 

Analyzer, eye diagram . ... 31/Aug. 

AnaJyzer. impedance .... 67/OcL 

Analyzer, protocol 88/OcL 

Analyzing wavelet 4M)ec. 

Annotating images 2*. Apr 

Amihacklash ti*-\ U ;e ............ 75/Feb, 

Aperture. ultrasound 45/Aug. 

Application help use mode] 90/ Apr. 

Arbitration 12/June 

Ar t I ti lecture, iniyet printer ....... 56/Feb. 

.Area fill quality IS/Feb. 

Assembly, print cartridge , WFefc 

Audio editor 52/Api 

A i Li .!i' a file types , 63/ Apr 

Audio hardware 66/Apr, 

Authoring, help system 94/Apr, 

Autoloader, DOS tape 12/Dec. 

Automatic test pattern generator 

• VI I'Cj WP*c> 

Availability 82, 9o/Dec. 

B 

Iktt kn|i, data 6, lL J , is.Uer 

Bag, ink ,,,......, i!> I ■ i 

Balinkin transformation _ i Feb 

Banding 19/Feb. 

Basis hEnrrinns i | 

Beam width, ultrasound 45/Aug. 

Bill of materials [BOM) tfVDer. 

Hit &rim ratio tests ,n Aul: 

I lii ' nial 37/Apr. 

Bleed 19, 2tVrVk 

Blocking 20 # &L/Fkb. 

Branching, u»t\ interaction ...... . 35/June 

Bus converters I7/June 

'.', a transaction ii/June 

C 

( Calculator, >Heni ific- ... tVAug, 

Calibration, HP El 113 10, S 



Calibration. delay 36^Dct. 

Calibration, impedance, 

modifiedOSL .... 70/Oct, 

Callback functions . 

■ility index .... 

ttion 

I 1 LAMP i channel-reseller 
and manufacturing process i 

ing, tool interaction 3">. June 

- eoVdevice model . . . 1 07/Oct, 

Chassis, foam . , , . . --2! 

Chirplel analysis . , .......... 52/Dee, 

Chirp! et transform ... . . < , 52/Dec. 

Choose boxes 15/ Aug* 

Cleanroom software 

engineering . 4i/June 

< "lii'Mi/serverarcliHfcuin*. 

HP MPower ...... IB, 25. 64/Apc 

Clew k distribution, Pentium GS/Dec. 

• 1m, k measurements 74 I tec 

l i alescence .................. 19/Feb. 

Coc^e ............. 18/Feb. 

Coherent write buffers 15/June 

I I Elaboration 23/Apr 

Color degradation 88/Apr 

Color flow imaging 44/Aug. 

Color iuaiuigenicni 31/Ap£ 

Color matching 3&/Apr, 

Coloi optimization 24/Feb. 

Color quality, uu\jel 18/Feb. 

I 'ni'M ramp 32/Ap£ 

Colorants. ,, , 33/Feh. 

Gommentatorj FDhl 9uun 

Comparator, pin 43, 45/Oct. 

( tomptlei Optimizations 37/Dec. 

Component placement 

machines 51/Juue 

Coi iij Miter's, business servers . . . li, 31/June 

t onditiriiHis. lor 1( testing 58/Dec, 

Connector, rlPSharedX 2&/Api 

i ontact angle, ink 30/Feb. 

Contenl ivpes, MIME 76/Api 

I uiii.'M diagram r>i;.Aii.Li. 

( 'tiiiiL-'xhial help rSl/Apr. 

i i mi i ol flow diagram 54/Aug» 

Control specification 54/Aug. 

Core server, MP SharedPrml 47/Apr, 

Covered ROM 9/Aug, 

Cracking 31/Feb. 

I i wmiiizafiou 32/Feb. 

Curl 18/Feb. 

I urrent nn irie aiuplii'ici 17/< Id 



Current-voliage impedance 
method 

Cyans . . 2&'June 



D 

l 1 \T drive 

Data dictionary 

Data-driven tesi systems 

Data flow diagram -" 

Datibeciuefi tv&veiel 17/Dee. 

DDS autoloader ... 12/Dec. 

DDS-2 tape drive rVDee. 

Debugger internals 39/Dec. 

Debugging optimized code 34/Dec. 

Defect-free software 4fl/June 

Delay line structures 53/Oct 

Delay vernier. CMOS 51/Oct 

Design leveraging , 35/Oct 

Design margin 19/Dec. 

Design plots 99/Dec. 

DesignJet 650C printer 6 P 50/Feb. 

DeskJet 1200C printer 6/Feb. 

Desktop configurations 14/Apr. 

Detector, flame ionization, SFC . . . 41 /Aug. 

Diagnostics, HP MPower 1,-vApr. 

] 'irieiential equations ._. 21/Aug. 

1 digital signal processing. 

LSI tester 59/Oct 

Digital transmitter 

characterization 29/Aug 

Digital video . . S/Api 

Directional bridge &&A h i 

I Hsplay modules , . 95/< )« r 

J Wsplay resources and rendenrm U Apr 

Distributed multimedia , L2/Apn 

Dislributed priority list 

arbitration 12/June 

L»ithering , tft ipi 

Dot gain 26, Web. 

Drawing modes 87/Feli. 

Drive roller, inkjet printer 74/Feb. 

Driver, pifl 43, 44/Oct. 

Driver redesign 52/Aug. 

Dr MPower 18/Apr. 

Drill-down &4K)d 

Drop detection H2/b\>h. 

Drop generation, in Kiel Il/Feb 

Drop placement errors , IK /Feb 

Drop size, Inkjet 10/Feb 

Drn|i volume, inkjM 12, 20/Feb. 

Drum, tape drive 9/Dec. 
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Drying time 28/Feb, 

DSP module &lA d 

Pu:-L]-flvi|iinn -\ imnsducers 50/Aug. 

Duplicate cache tags 14/June 

Dye selection 24/Feb. 

E 

[mli i piaJity, inKJet IS/Feb 

Electrical ove-rctress testing .... IGfVf )ei. 

Electrical system, ink]* t printer . . . 152/Feb. 

Electrostatic discharge Testing . . . IU0,'< )ci. 

Engineering uniis conversion 21/Oct. 

Enterprise modi-liny 

and simulation . . 8G/Dee. 

EPP foam chassis 23/Aug. 

Error diffusion 91/Feb. 

Error trace capture . 36/Aug. 

Event-based debugging 33/Dec. 

Event matrix 55/Aug. 

Events, calculator lG/Aug, 

Evolutionary delivery, 

cleanroom 42/June 

Excitation supply 14/OcL 

Executable test suite hi.' ■vi. 

Expanded polypropylene * * 23, \i i.u 

Egression evaluation ♦ . . * 39/Dec. 

Extinction ratio 30/Aug. 

Eye diagram analyzer 31/Aug. 

Eveline diagram , 32/ Aug- 

F 

Fax Client 54/Api; 

Fax databases ,....,... 55/ Apr. 

Fax server 55, 59/ Apr. 

Faxing documents 9. 53/Apr. 

FDD! Ring Manager &§$ fcfc 

FIJI 82,85/Doo. 

File manager HP VUE 3.0 21/Apc. 

Filters, printing ♦ « 49/Apr 

Filters, root raised-cosine 64/Oct 

Firmware design, autoloader ..... 15/Dec. 

Firmware, inkjet printer G4 T 85/Feb, 

Fixintvs impedance 

measurement , 73/OcL 

Foam chassis 23/Aug. 

Forecast quality 80, S5/Dec, 

Foreign language format, 

HP Help System 85/Apr. 

Frame relay 

conformance testing 83/Oci. 

Functional verification 43/June 

Fuzzy composition 56, til /June 

Fuzzy family assignment 

heurist ic 57/June 

Fuzzy logic .......♦,,,,,,., 51/June 



Fuz/ylogir. IIP El Hi 3&Oi t 

Fu/:/\ relations . .:■:& 

Fuzzy set theory .l/.lm 

G 

Gabor transform 44/Dec. 

Gamut, color ...... lS/Ft h. 

I 1 in lal help 92* 'Apr. 

Graphical user interface 2IVApr. 

Grayscale 37/ Apr 

« ii i ■> ,-<\\ board heurist ic . . . , 53/Jime 

Grid-centered method 90/Feb, 

Grid-iuterseciiun method iKj/Feb. 

H 

Haar wavelet . , H j I % 

fhirliy-Pirbhai state machine 28/Dec 

Heads, tape drive 7/Dee. 

Healer, inkjet 15, 23.32. ui. 7:i.*Vk 

Help dialogs ,,,,... 81, 84/Apn 

Help entry points 81, 91/Apr, 

Help file compression 

and decompression ti I- \:u 

Help file system 80/ Apr. 

HHp in formation models . 92/Apr. 

Help-smart application 82/Api: 

Help use mod. 1 90/Apr. 

Help volumes . 82/Apr, 

High-Q measurements 7tn »n 

High-throughput amplifier ...... lfi/Oct, 

HP-PAC ♦ . 23/Aug. 

Human body model 106/Oct. 

Hypertext links 93/Apr. 

I 

IC, delay vernier 51 /Oct, 

IC. pin electronics 42 T 44/Ocf. 

IC, processor interface 14/June 

IC lest system, mixed signal 42/Oct, 

JFVM function 43/Oci, 

[mage compression 

and decompression 39/Apr. 

tmags conversion . . , 41 /Apr, 

Image files . . > 37/Apr 

Image manipulation . , 41/Apr 

Image processor 86. Feb. 

[mage -scaling 41/ Apr. 

Impedance analyzer .•;.•,..... WIfQct 

Industry standard file types ...... 39/ Apr. 

Ink design, black 13/Feb. 

Ink design, color 23/Feh, 

Ink level indicator 53/Feb. 

Ink-receptive coating 28/Feb. 

Inks, inkjet 33/Feb. 



Inpul fonns Li/Aug. 

Input/output subsystem L6/June 

Inspections, code 61/Aug, 

Umj 1 1 mentation amplifier 17/Oct, 

hm-uraied driver printliead >, 41/Feb. 

Intellectual control ItfAJune 

lulenuHt r. slate table 2 4/1 >ec. 

hiterprocess communication 14/ Apr 

Interval . monitor 99 /' )n. 

Interval, update 99/Oct 

Inventory 85, 88/Dec. 

1SS 

(Instrument Software System) .... TIVOct. 

Item hel| i , 82/Apn 

I-V impedance method 68/Oci., 



JiTlei, < lock 

Jitter, CMOS inverter 
Jitter, transmit fee? 



. , G8/Dec. 
. . 54/Oct. 

. . 3(>/Aug. 



Must-enouglHesi" strategy 30/Oct 



Khoros system 
Knowledge worker 



. . iS/Dec. 

. ,, 10/Apr. 



h ;r : l'- : system 

Language interface 

I. tnguage, rostplan 

Language, TfCN 

Languages, test suite 

Lurgr-format plotter 

Lead time 82, 

Legal primitive evaluation .... 45, 

Level 1 diagram -, 

Library, operation modular ....... 

Line quality, inkjet 

Linear phased-array transducers . . 

Linearity, tape drive . » 

Load, active 43 ; 

Localizahility 

LSI test system, mixed signal 

M 

Mlicl 1 TlL.il li ItlU S3, ^'-JUILI:- 

Maciiine n\odel. ESD 106/Oct. 

MAQeSS nodes , 105/Oct. 

Maga/inc. iaj>f autoloader 14/Dec. 

Mail composer .... 74/Apr. 

Mnil system 7UApr. 

Mail transfer agent < 73/ Apr. 

Mail user agents 72/Apr. 



24/p>b. 
9iTeh. 
(>2/<)ct. 
84/Oci 
84/Oct. 
f>0/Feb. 
85/Dec. 
4 7/ J tine 
5fi/Aug. 
02/Oct. 
18,Feb. 
46/Aug, 
. 9/Dec 
, 45/Oct. 
89/Apr. 
42/Oct. 
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Management information base 

88, SB/Oct. 

Managing shared windows WApr, 

Manufacturing, computer 2&0une 

Manufacturing 

enterprise model . . . 82, Hi/Dec. 

Manufacturing test optimization . 3QfOCL 

> al SftJ 

Map, logical 89,37, 10 

, frig, FDDI ring 
topology 39, 94, 97/Oct. 

Mask measurements 36/Aug. 

Marching fonts 34 Apr. 

Mathematics, calculator 19/Aug. 

Maxiclient 15/Apr. 

\1< ;ik state machine . . . . 27/Dec, 

Measurement modules, 

HPHD200Q .,,...... ..... 7/Oct. 

Mechanical design, 

tape autoloader 14/Dec, 

Mechanical design, computer 26VJune 

Mechanical design. inKiet printer . . 58/Feb, 

Media path, inlgei printer 72/Feb. 

Memory configurations! HP4SGX , . 7/Aug. 

Memory interleav inu 19/June 

Memory size conventions S/Jime 

Memory system . , 1.9/June 

Message I \ » i t km t < >r. S< >ft Bench - . - 34/« fune 

Metamail ,.*,..«.♦ 757Apr. 

'■■!' ei wavelet 46/Dec, 

mime [Multipurpose 

Interne! Mali Extensions) .-. . 72. 75/Apr. 

Mimetypes 7:s / \pi 

Minii Tienr 1 5/ Apr, 

Modes, irikjet printer 21, 35/Feb. 

Mottling.. MF&x 

ModeJ deveioprrtenl ofr/Feb, 

Model, stepper motor 75F«>k 

Modeling, enterprise S0/Dec. 

Models. 

manufacturing enterprise 9l)/Dec. 

Module testing . . lirt/Doc. 

Moore state rrtachtne 27/Dec 

Morlel w;i\elH ..--.., 46/Dec 

Mother vvau-lel 44/Dee. 

Motions, tape autoloader 1 If tec 

MPEG-1 

[Moving Pictures Expert Group) , . . 9jtt$H 

Multimedia editor TfflApz 

Multimedia environment . ., 10/Apr. 

Multimerlia mail 71 ipi 

Multiprocessing computers . . . . 6, 31/June 

Muiisell system 24/Feb, 



N 

Neighbor information ... 9&OeL 

Network Advisor, FDDI SSfOcv 

Network backup lM3ec. 

o 

Office Paper Program 
i 'inline application help 

« "inline help 12, " 

Operational test release vectors . . 5M)ec. 

Order-to-delivery time 82. $■■ 

Overvoltage protection 

P 

Packages, HP DDE 38/Dec. 

Packaging, print cartridge 53/Feh. 

Packaging technology, foam 23/Aug. 

Paiette 37/Apr. 

Paper advance, Inkjet printer 39/Feb. 

Paper, Inkjet IbTFeb. 

PA-RISC % 31/June 

Part commonality !■»: | I N i 

Partnerships 38/Oct 

Pi L o( language frVI-Vh. 

Peltier cooler I 1 

Pentium clock design . . 6H/Dee, 

Performance. multiprocessor 21/June 

Pigment dispersion IB Feb, 

Pjpeiim CPU 1 V.I ime 

Pipeline, printing r>I/Apr. 

Pipelining HPEI413 20/Oct. 

Pixel mapping 34/Apr. 

Pkcemenl machines 51/June 

Plotting, 3D calculator 17 

Polyester media, inkjei 28/Feb. 

PostScript prinier , fVTeb. 

Precision Bus, IIP lWJune 

Preheater, im\jet printer . . . 15, 37. 73/Feb, 

Pressure scanner 37/1 tel 

Prewai'inhit] printhead 13/Feb. 

Primary family 52/June 

Priming. inJsjel i artiidge TUFeh 

Prim: cartridge alignment :itv'Feb, 

Print cartridge development nvFi u 

Pnnr cartridge Bxturing 

;irt ridge maintenance 67/Feb, 

Print client 467 Apr. 

Print quality, 

Inkjet 9,16, 18,22, 35, 56/Fcb. 

Prim quality tester So/Feu. 

Primers, roJorinKJel (VFeb, 



Printhead. inkjet 41 Feb 

Printing pipeline 51 Apr 

Process specification . . . "4 Aug 

Processor board 13/June 

Processor interface emp 14,. June 

Processor memoir bus 10/June 

Processor modules I3/June 

Produ 1 1 -specific files I -3/Aug. 

Production cost fiowthrough 
(FCFT 

Progn 

Pseudorandom binary sequence . . 29/Aug. 

Puddiin- 21 Fth 

Pump, SFC 

Q 

QFD house of quality , . . . . . . , 47/Aug. 

Quad . .... lOtfune 

Quick help 81, &1/Apr. 

R 

Range s^iiching 18/Oct 

Raster operations 87/Feb. 

Receiver service 2 5/ Apr, 

Reengineering 86/Dec. 

Remote debugging 3G,40/Dec, 

Resolurion enhancement 36^Feb, 

Retargetable debugger , . .... 3o. I fee, 

Ret lun-on-in vestment model. 

soitwaje inspections (j5/De<\ 

nient^ 
si»liware testing , ♦ tiS^Dec 

RUMPTRs !J/Ang 

R' Mat if hi. magazine Ki u ■ 

Routine editor 3*5/June 

Routine engine , 35/June 

Routine manager , 35/June 

RPI 82. 85/T.icc 

S 

Sritety slork 82/Dec. 

Sales riml I 

r me king system fiO/Dee. 

Sall.ri and Key filter 1 1 « tet 

Sampling, harmonic repetitive 32/Aug. 

Sr;il. wavelet 4rv f Dec. 

Scan cell ...>?, 57/Dec. 

Sereen calibrator [>'>, F< '■ 

Seam teams , . i > I VI i 

Self-test , 25/OcL 

Sti h ler/receiver architecture, 
UPSliaredX :: I Apr, 
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sfindmail 73/Apf. 

Servers, business 6, 31/Jtine 

Service processor 22/Juni 

Signal conditioning plug^n (SCP) . . 9/Oci. 

Simple Model 82 I irr 

Simulation, enterprise ...••....*. 80/Dec. 

Six-sigma 40/June 

Snoopy protocol , . » ... 1 1/June 

Soft Bench Message Connertor . . . 34/June 

Software, data driven 62/Auft 

Software inspections lft/,lnne, til /Dee. 

S« »fi vvan- mei p it a . . « 61/Dee. 

Sufi ware testing 62/Dec. 

Speculative prefetch 1 s .1 ■ i. .. 

Speed, inlget. printer 9, 14/Feb. 

Split bank . . .... 51/June 

Spray 19/Keb. 

Spring-bag prim cartridge ♦ 49/TVb 

StahiliH smMstieal 68/Dea 

State table generation 21/Per, 

State machines , . 21, 27/1 u v 

Statistical testing 47/.Iune 

Stepper motor 75/Feh. 

SI rain guages Ufcft tet 

Si met tire chart 50/Aug. 

Sin inured analysis and design . . . 52/Aug. 
Stnictuied daia. cleaurooiti 1 7. Jl un- 
structured specifications. 
cle;mroom -ill/Junr 

Style manager WM * l 

Supercritical fluid 

chromatography 38/Aug. 

Symbol table 38/Dec. 

Syntax trees 39/Dee. 



T 

Tap. . hhS-J 7/Dec. 

Tape ditve, Id >S-2 fi/Dec, 

Telephony W Apr, 

Temperature control, print head , r , 12/Feh, 

TEMPOS 9/Aug. 

Test access port (TAP) SbVDec. 

IW ■ xcrutivo 64/Aug. 

Test patterns 55/Dec. 

Ti'si planning GMJec. 

!>-i software^ duia-driven . . . *. . . 62/Aug. 

system, LSI !. 

Test vhi u n development KflEtec. 

'I' ^ling, prinl cartridge . , . , * 79/Feb* 

Text quality, in^jet . 9, 35/Feb* 

Thermal Ceding 42/Feb. 

Thermoelectrk cooler 40/Aug. 

Tli ree-oparup amplifier 17/Oct. 

Time shift, wavelet . TVLh-r 

Timing enviroiLiiieni , 69/Dec. 

Tolerance mechanisms , 7U/Dec. 

Tool interaction 34/June 

Ji:n isfiucers, linear ultrasound . . , 13/Aug. 

Transition information, state 2:\ /Her. 

Transmitier characterisation >. 2&/A)0g 

Transparency film, Inkjet * « . 28/Feb, 

Trapezoidal imaging 5(1/ Aug, 

Turbine test !Vun. 

u 

rilrasound transducers. 

vascular 43/Aug. 

Iser interface, calculator 13/Aug, 



Vascular ultrasound transducers . 1,'1/Aug. 

software , 70/Apr. 

Video technology 68/Apr 

View volume 17/Aug, 

Vin 1 jal DMA G7/Apr. 

\ is< osity. ink 30/Feb. 

Voice ............... 15/Dec. 

Vuepad ;..... .■ i-i 7 I. ■■" A| r 

Vuemime ...•..♦«.»,,«. 70/Apr. 

VXIbus , fi/Oct 

W 

Wait time banding , 19/Feb« 

Ward- Mel lor stale machine 2S Dec 

Waveform database 55/Dec. 

Wavelet analysis . . , 44/Dec. 

Wavelet transform 45/Dee. 

Wait the bus 1 l/.June 

Whiteboard ... . , 28/Apr. 

W1P 84, 85/Dec. 

Workspace manager, 

HPVUE3.G 21/Apr. 

Wrinkling 31/Feb. 

WYSIWYG printing 86/Apr. 

XYZ 

X stations HVApr. 

X video software 70/Apr. 

Yn,( r 37/Apr. 
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HP 4SG i tX Scientific Graphing Calculator 
HP 3 Business Compute 

HP; itaits 

Dee. 
HPi" June 

::ess Serve* .lime 

IIP 21255B Linear Phased- Array 

•i 3ai I'll ntsound Transducer . . Aug. 

HP 2125SB Linear Phased-Array 

Si uiul Transducer Aug. 

HP 71 "ul a Eve Diagram Analyzer Aug. 

HPC1533A DDS2 Tb&e Drive , 

HP C1553A DOS Tape Ain.-.Ji rader Dee. 

HP EHI3 64 channel scanning anulug-?»-digituJ converter 

HP E1414 pressure scanning malog-to-digital converter < let 

HP DesignJet - ■ ~< « m plottej Fob. 

up DeskJet 129QC printer , Feb. 



HP DeskJet ._ PS PostScripr printer 

HP Distributed Debugging Em i DDE Dec. 

rl205A S § Aug. 

HPHD2000dai 
HP Help Devel 
HP Help System 

IIP u Apr, 
HPInstair Apr* 
HPMJ Apr- 
HP-] sas and Packaging Technology Aug. 

HP SharedPrint . . Apr. 

HPSharedX Apj 

HPSonos Mmki ( ardiovasculai I id Imaging System - Aug, 
HP Teleshare Ayr- 
HP VUE 3.0 .- . ,,.. Apr. 

Si iJ't I letit h Message Connector June 

Whiteboard Apr. 
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